Strided prefetch: mostly evil. I've rewritten the predictive prefetcher; new version only detects forward sequential streams. Will propose for upstreaming soon. In the mean time feel free to check out:
https://github.com/delphix/delphix-os/commit/13cf8efe4b6b10930b478a15f9de92880bbdd412 --matt On Sat, Apr 4, 2015 at 7:59 AM, Alexander Motin <[email protected]> wrote: > Hi. > > Experimenting with SPEC NFS benchmark I've noticed significant amount of > CPU time, spent by ZFS prefetcher code. The most interesting is that > time was spent when prefercher was called not for data access, but by > dnode_hold()->dbuf_read() when accessing blocks of DMU_META_DNODE(os). > Further investigation shown that prefetcher probably misinterprets > random access to very large number of files (DMU_META_DNODE records) as > strided in some odd ways, that generates many pointless prefetches. > > Source of that behavior I see in excessive softness in strided streams > handling in prefetcher. Sequential streams require each following block > to be read to move further. Strided stream same time is much softer -- > it count any request within zst_len range of the next stride as hit, > triggering another large portion of prefetch. As result, if some random > prefetch stream manages to become strided (that requires only thee > luckily placed requests), it already has higher chances to live longer, > and if after that it accumulates some zst_len -- it may jump forward and > backward generating random prefetches for a very long time. > > I've made a simple patch > (https://people.freebsd.org/~mav/strict_stride.patch) that gives strided > prefetch same strict limitations as sequential one has. That completely > fixed the problem described above, while strided patterns generated by > iozone are still working as such. My only suspicion is that may be > present algorithm was designed for some more odd access pattern, that > allows reads within stride to be done not sequentially, but I can not > imagine in which applications such pattern could be useful enough to > tune for it. > > Am I missing something? > > -- > Alexander Motin > _______________________________________________ > developer mailing list > [email protected] > http://lists.open-zfs.org/mailman/listinfo/developer >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
