2018-03-25 13:48 GMT+02:00 Michael van Elst <mlel...@serpens.de>: > 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.
