On 5/9/18 10:32 PM, Paolo Valente wrote: > > >> Il giorno 09 mag 2018, alle ore 22:49, Jens Axboe <axboe@xxxxxxxxx> ha scritto: >> >> Omar had some valid complaints about the previous patchset, mostly >> around the fact that we should not be updating depths on a per-IO >> basis. He's right. In fact, BFQ oddly enough does it from the >> ->limit_depth hook, but the shallow depth counts remain static. >> >> This series cleans that up the ->limit_depth() handling, and keeps it >> out of the hot path. >> >> Mike, this should (still) fix your hangs with BFQ. This series is >> (functionally) identical to the bundled up version I sent you earlier. >> > > Only one question/curiosity: is performance unaffected by the lowering of > the wake batch counts? It's hard to discuss performance within the realm of "it hangs without it", there's just no way around this. That said, We still have the rolling waitqueues (default is 8) which also helps in reducing the overhead on both wakeups and adding to wait queues. So we should still be quite fine. As it so happens, there's another bug in wake batch accounting in sbitmap, which would have defeated much of the win over time anyway. New series coming with that extra patch. -- Jens Axboe
