I thought about this some more and come up with another "simple" approach that didn't require me understanding too much code, but does - I think - address your concerns.
I've changed the heuristic to avoid any throttling on PF_LOCAL_THROTTLE task if: - the global dirty count is below the global free-run threshold. The code did this already. - (or) the per-wb dirty count is below the per-wb free-run threshold. This is the change. This means that: - in a steady stated, all bdis will be throttled based on their (steady state) throughput, which is equally appropriate for PF_LOCAL_THROTTLE tasks. - a PF_LOCAL_THROTTLE task will never be *completely* blocked by dirty pages queued for other devices. This means no deadlock, and that is the primary purpose of PF_LOCAL_THROTTLE. - when writes through the PF_LOCAL_THROTTLE task start up from idle - when there is no current throughput estimate - the PF_LOCAL_THROTTLE can be expected to get a fair share of the available memory, just as much as any other writer. This was the possible problem with treating PF_LOCAL_THROTTLE just like BDI_CAP_STRICTLIMIT. So I think this is a good solution. Thoughts? Patches follow - I've address the comment formatting issue. Thanks, NeilBrown
signature.asc
Description: PGP signature
