Re: [PATCH 1/2 V3] MM: replace PF_LESS_THROTTLE with PF_LOCAL_THROTTLE
From: NeilBrown
Date: Wed May 13 2020 - 03:16:44 EST
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
Attachment:
signature.asc
Description: PGP signature