In D40327#918269, @mjg wrote:

i wonder if this is the right approach to begin with

have you considered a different take on it: instrument all functions with a timestamp grab on entry/exit. this will have to make sure tail call is disabled. that what you will get an almost complete picture who takes time, but in some cases it may still require extra effort to find out why (say a func is long and is doing a bunch of unrelated ops).

LGTM

Could we make a deal on that? I writeup a patch for the 500x case today, and you can test it and compare against the current results?

In D39916#914489, @arichardson wrote:

Rebased on latest main.
@cperciva it would be great if you could test how much this helps your usecase.

In D39973#910065, @emaste wrote:

LGTM with one nit

Update comment to match new reality.

Looks good to me. Thanks for cleaning this up.

Please go ahead and commit and just list me as approving it. I'm sure it will be ok. :-)

You're going to be adding test cases for this in libmd, right?

In D36667#872465, @pkubaj wrote:

@cperciva
Since this affects running CURRENT in a VM, can you take a look at that issue?

Another question: Do you want to respect vm.swap_maxpages? Or just allocate the swap space and let the kernel potentially issue a warning about the device being too large and not being fully utilized?

@cperciva what would work best on EC2?

It probably makes the most sense to disable the growfs swap addition in that case. These scripts don't really handle that situation correctly, where swap could be prioritized. But the growfs swap will not be added if there is swap in the fstab already.

This sounds like a good idea in principle. A couple things which come to mind:

Tested by "void", confirmed that this eliminates the warning from his bhyve VMs.

In D37082#842118, @mav wrote:

I always wondered whether kernel could try harder to reduce the number of segments below the number of pages to help hardware that can benefit from it. But you are right that current kernel does not even try to allocate the bounce pages consequently, so allocating more pages than segments supported does not make much sense.

In D37082#842117, @jhb wrote:

(But I think this is probably fine to do). One odd thing to note is that we always map at least 1 page it seems. That is, it seems to me that bz->total_pages should just be the MAX(all possible tags). But it isn't, in fact it is the SUM(all possible tags) that is capped at MAX_BPAGES. That seems rather odd to me. I would expect the logic in general to be more of ...

In D37082#842116, @jhb wrote:

It might be nice to apply the same change to all the bounce backends on other arches as well?

Alexander, John, can you chime in on this?

In D30006#841936, @ehem_freebsd_m5p.com wrote:

@cperciva could I persuade you to try testing D30006? I'm cautiously optimistic it does in fact work for x86, but the problem is I'm setup for testing ARM64, not x86.