keeping some % of reserve for root would be good,, equivalent to _falloc_noinstall

this can __assert_unreachable which will in production kernels will tell the compiler the 2 options are the only valid ones

This would not expose any detail apart from the fact that pipes have to allocate space to hold data, which is an integral part of the mechanism.

should not this instead limit how much memory is used to back pipe buffers?

Sorry, I forgot to link the benchmark results from a previous iteration of this patch.
The metrics I've gathered show that this approach does reduce NOFREE fragmentation.

one could add a flag to mountroot indicating the system knows some stuff may be missing and to fail the mount if that's the case, should be very easy to handle. then a wait round and another mount call but without the flag

can this only wait for usb if no root device is found? then whack the tunable

I'm taking this over from Kristof as a "favor".

refs need to be converted to atomics, then you can grab one without taking the lock

how does this look like in terms of valid lock ordering?

did fragmentation drop though?

Given that we're unlikely to see new consumers of lockmgr going forward, I wonder whether sleepgen would might someday be useful for avoiding the vnode interlock in some cases? If not, then this seems like a lot of machinery to deal with one lock, though the diff isn't too big.

This needs to retain proper authorship, so the Author field still needs to be hps. Add the end of the commit message you should mention this was extracted by you from a bigger patch of his. So add that, drop "in memoriam".

why even support something like this?

Further testing by other people confirmed my worry this is too trivial to fix the problem without running into other side effects, thus I'm dropping the thing.

i386 kernel is being retired

First and foremost my apologies this fell through the cracks.

In D43488#991564, @pjd wrote:

In D43488#991394, @mjg wrote:

What's the motivation here? If you are running into scalability problems, it has to be allproc and proctree locks (amongst others).

Yes, scalability is the main motivation. We have a machine that slows down considerably when we reach >10,000 process (64 core system). allproc and proctree are the main problems. This change is just a low hanging fruit where we can easily eliminate a global lock.

this macro should be eliminated, not exposed

What's the motivation here? If you are running into scalability problems, it has to be allproc and proctree locks (amongst others).

Linux folk explicitly designed openat2 to be extensible, so I expect it is going to pick up explicit "official" usage down the road.

sounds like the thing to do is to add openat2 so that this automagically works, instead of a freebsd-specific flag

why is this port still a thing

@markj ping?

First of all my apologies, this somehow fell through the cracks after i pinged.

• correct diff

So again what's the benefit of bubbling up ENOSYS? I assumed it would at least get handled in a post-vop hook instead of going all the way up to the caller.

if it does work with the patch, you should paste how dmesg looks like with it

according to your own copy from dmesg this failed to attach, so it does not work?

The patch looks correct, but commit message needs some work.

I massaged what I mean into a patch, with your nullfs change as basis:

In D42603#972555, @kib wrote:

I plan to do something different after this patch goes in.
Most complications for fs come from the need to call vn_generic_copy_file_range() as fallback. I intend to make a special return code (or just repurpose ENOSYS) to ask VFS to do that after VOP call. It seems that this even eliminates the need of the flag to allow cross-mount copies, not sure completely. That would fit the idea that VOPs should implement just fs-specific code.

The VFS layer trying to babysit all filesystems is a long standing design flaw, which adds overhead to everyone and only makes optimisations clunky. For example for almost all filesystems VOP_CLOSE has next to nothing to do and most definitely does not need write suspension nor the vnode lock (and for zfs the routine is a nop) -- if there was no attempt to decide for the filesystem what it needs, there would be no problem.

vn_copy_file_range passes down vnodes from different mount points and all filesystems implementing the vop (apart from zfs) have an explicit check that mount points patch. iow the check that this is an instance of the same filesystem type is redundant for their case.

If you can rebase both changes and show me how to collect fragmentation stats I can test this against a full ports tree build.

I don't know if the kernel is in shape where this can be properly evaluated.