During the retest of the partition alignment fix, some extreme drops of the free pages have been found.

In D45379#1035368, @imp wrote:

In D45379#1035342, @seigo.tanimura_gmail.com wrote:

Having said that, I will try reallocating those partitions with the 1MB boundary alignment later and see if there are any changes.

I think it will make things a lot better.

In D45379#1035253, @imp wrote:

The other question I have: why is the swap pager going so nuts? Normally, back pressure keeps the source of I/Os from overwhelming the lower layers of the system (which is why allocations are failing and you've moved to a preallocation). Why isn't that the case here?

In D45379#1035237, @imp wrote:

In D45379#1035197, @seigo.tanimura_gmail.com wrote:

root@pkgfactory2:~ # swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/nda1p1      67108820  7964000 59144820    12%
/dev/nda2p1      67108820  7987416 59121404    12%
Total           134217640 15951416 118266224    12%
root@pkgfactory2:~ # gpart show /dev/nda1
=>       40  134217648  nda1  GPT  (64G)
         40          8        - free -  (4.0K)
         48  134217640     1  freebsd-swap  (64G)

root@pkgfactory2:~ # gpart show /dev/nda2
=>       40  134217648  nda2  GPT  (64G)
         40          8        - free -  (4.0K)
         48  134217640     1  freebsd-swap  (64G)

Both of these drives are mispartitioned. For best performnace they should have at least 1MB if not more alignment for the first partition. Do we really need to add code to handle mis-aligned partition performance problems that are pilot error?

Poudriere-bulk(8) Test Results

• The OS version has been updated to 14.1-RC1.
• kern.geom.reserved_new_bios and vm.swap_reserved_new_bios are set to 65536, the default values.
• The tendency of the results are the same as https://reviews.freebsd.org/D45215#1033442.

In D45379#1035175, @olce wrote:

Prior to any analysis, I assume you're doing this to fix some memory allocation deadlocks in the swap path. Could you describe a concrete scenario where you experienced a problem that this patch solves? Were you swapping to some regular partition, an encrypted one, or some vnode or zvol?

Diff Updates

• The bio allocation accepts the caller-supplied uma(9) zone for both non-blocking (g_new_bio_uz()) and blocking (g_alloc_bio_uz()) allocations.
• The bio cloners (g_clone_bio() and g_duplicate_bio()) inherit the uma(9) zone of the original bio.
• One prerequisite and three usage diffs submitted separately.
  • Prerequisite:
    • https://reviews.freebsd.org/D45378 Publish the name strings of the uma(9) zone. Intended for the logging of the uma(9) zone names upon an allocation failure.
  • Usages:
    • https://reviews.freebsd.org/D45379 The VM swap pager.
    • https://reviews.freebsd.org/D45380 The nvme(4) namespace driver.
    • https://reviews.freebsd.org/D45381 The xen(4) blkback driver.
• Optimization.
• The new KPIs and loader tunables are covered in the man pages.

Updated Test Results with Fix

• The test results in https://reviews.freebsd.org/D45215#1032189 still had some port build errors, so they all have been fixed locally.
• The fix has been rebased to 14.1-BETA3. (2a964a7fc3)
• The tendency of the results are the same as https://reviews.freebsd.org/D45215#1032189.

One problem looked over regarding M_USE_RESERVE:

Patch for Bio Alloation Stats
{F84091654}

Simplify the change accordingly to the reviews up to https://reviews.freebsd.org/D45215#1031442.

In D45215#1031630, @imp wrote:

What does nvmecontrol identify ndaX say here? What's the optimal I/O boundary? And maybe we should just have a knob to disable trying to use it.

Key findings out of quick codewalk over g_new_bio() callers
sys/dev/nvme/nvme_ns.c, the nvme(4) namespace driver, calls g_new_bio() in the heaviest manner.

• A lot of child bios are allocated in a burst.
• The child bios are always allocated in the non-blocking way by g_new_bio(), regardless from the bio commands.
• The child bios are allocated and freed within the nvme(4) namespace driver.

PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279021

This change is to be applied to stable/13 only (obviously). So maybe I'm not understanding your question?

Follow style(9).

Follow style(9).

Follow style(9).

Follow style(9).

Are you going to apply this change to stable/13 only, or "backport" it to main first?

Merged to stable/13 as d119f5a194.

Reflect https://reviews.freebsd.org/D44217#1008900.

Reflect https://reviews.freebsd.org/D44217#1008900.

Superseded by https://reviews.freebsd.org/D44218.

Superseded by https://reviews.freebsd.org/D44217.

Reflect https://reviews.freebsd.org/D44217#1008785 .

Reflect https://reviews.freebsd.org/D44217#1008785 .

In D44177#1008410, @seigo.tanimura_gmail.com wrote:

In D44177#1008409, @kib wrote:

nullfs should be served, and is served by normal vnlru thread. If you need something special, -o nocache is the solution.

Then is it OK to make the nullfs lower vnode caching configurable via sysctl in the system-wide way?

The applications that mount the nullfs filesystems dynamically can then enjoy the solution without modifying the applications.

This fix has been confirmed to achieve the same effect as https://reviews.freebsd.org/D44177.

Unlike https://reviews.freebsd.org/D44178, this fix does not depend on the ZFS fix and can be merged independently from it.

Unlike https://reviews.freebsd.org/D44177, this fix does not depend on the ZFS fix and can be merged independently from it.

Target branches: stable/13, releng/13.3, releng/13.2
Backport of: https://reviews.freebsd.org/D44217
Revised diff of: https://reviews.freebsd.org/D44178

Target branches: main, stable/14, releng/14.0
Revised diff of: https://reviews.freebsd.org/D44177

In D44177#1008409, @kib wrote:

nullfs should be served, and is served by normal vnlru thread. If you need something special, -o nocache is the solution.

In D44177#1008050, @kib wrote:

Putting fuse and nfs aside.

I think the best route is to add some zfs fs property (I do not know what is the proper way) to set MNTK_NULL_NOCACHE on that fs.

Thanks for your input.

Target branches: stable/13, releng/13.3, releng/13.2
Backport of: https://reviews.freebsd.org/D44177

Target branches: main, stable/14, releng/14.0

Target branch: releng/13.2
Backport of: https://reviews.freebsd.org/D44173

Target branches: stable/13, releng/13.3
Backport of: https://reviews.freebsd.org/D44173

Target branches: stable/14, releng/14.0
Backport of: https://reviews.freebsd.org/D44173

Target branch: main

Target branches: stable/13, releng/13.3, releng/13.2
Backport of: https://reviews.freebsd.org/D44171

Target branches: main, stable/14, releng/14.0

Target branches: stable/13, releng/13.3, releng/13.2