On 4/27/20 10:30 PM, Andrew Morton wrote:
On Sun, 26 Apr 2020 20:12:58 -0700 (PDT) David Rientjes <rientjes@xxxxxxxxxx> wrote:
GFP_ATOMIC allocators can access below these per-zone watermarks. So the
issue is that per-zone free pages stays between ALLOC_HIGH watermarks
(the watermark that GFP_ATOMIC allocators can allocate to) and min
watermarks. We never reclaim enough memory to get back to min watermarks
because reclaim cannot keep up with the amount of GFP_ATOMIC allocations.
But there should be an upper bound upon the total amount of in-flight
GFP_ATOMIC memory at any point in time? These aren't like pagecache
If it's a network receive path, then this is effectively bounded by link speed
vs ability to deal with the packets quickly and free the buffers. And the bursts
of incoming packets might be out of control of the admin. With my "enterprise
kernel support" hat on, it's it's annoying enough to explain GFP_ATOMIC failures
(usually high-order) in dmesg every once in a while (the usual suggestion is to
bump min_free_kbytes and stress that unless they are frequent, there's no actual
harm as networking can defer the allocation to non-atomic context). If there was
an OOM kill as a result, that could not be disabled, I can well imagine we would
have to revert such patch in our kernel as a result due to the DOS (intentional
or not) potential.
which will take more if we give it more. Setting the various
thresholds appropriately should ensure that blockable allocations don't
get their memory stolen by GPP_ATOMIC allocations?
I agree with the view that GFP_ATOMIC is only a (perhaps more visible) part of
the problem that there's no fairness guarantee in reclaim, and allocators can
steal from each other. GFP_ATOMIC allocations just have it easier thanks to
lower thresholds.
I took a look at doing a quick-fix for the
direct-reclaimers-get-their-stuff-stolen issue about a million years
ago. I don't recall where it ended up. It's pretty trivial for the
direct reclaimer to free pages into current->reclaimed_pages and to
take a look in there on the allocation path, etc. But it's only
practical for order-0 pages.
FWIW there's already such approach added to compaction by Mel some time ago, so
order>0 allocations are covered to some extent. But in this case I imagine that
compaction won't even start because order-0 watermarks are too low.
The order-0 reclaim capture might work though - as a result the GFP_ATOMIC
allocations would more likely fail and defer to their fallback context.
