Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86

[Jaromír Doleček <jaromir.dolecek%gmail.com@localhost>]

2018-03-25 13:48 GMT+02:00 Michael van Elst <mlelstv%serpens.de@localhost>:
> For some reason it's not per block. There is a mechanism that moves
> an 8kbyte window, independent of the block size. You can easily change
> the window size (I'm currently experimenting with 128kbyte) by building
> a kernel with e.g. options UBC_WINSHIFT=17.
>
> Independent of how the scaling problem will be handled, I suggest to
> increase that window to at least MAXPHYS.

I think the file mapping window doesn't need to really be tied to MAXPHYS.
But values over MAXPHYS will probably currently [*] not give further
significant speedup for filesystem I/O, unless data is being read from cache.

One thing to note is that this size is used for all file mapping windows, so
having too big value could case KVA shortages on 32bit platforms. I think
original UBC_WINSHIFT tried to balance most usual file size and overall
KVA use in kernel pmap, similar to e.g. MAXSLP works. Maybe bump
to higher value on 64-bit archs only?

If the bump would work, I think we should pull it up to 8.0 too, at this
is probably least likely to break anything out of the proposed options.

Did the experiment work?

Jaromir

[*] I hope to get tls-maxphys integrated for 9.0, by then maybe we need
to revisit this. It would be also nice to revisit the need to map the
memory to kernel pmap in order to do the I/O.