]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
mm/page_alloc: treat RT tasks similar to __GFP_HIGH
authorMel Gorman <mgorman@techsingularity.net>
Fri, 13 Jan 2023 11:12:13 +0000 (11:12 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 8 Nov 2024 15:25:55 +0000 (16:25 +0100)
commit9da195a2d35b7631c59b80fcc58aeec67e3d1385
tree6754e2e3d04ae7b14a72ecd73ec1f9685c7eadc0
parent92e52ff398b5574d4ea0cfba878ebbb1da6d1260
mm/page_alloc: treat RT tasks similar to __GFP_HIGH

[ Upstream commit c988dcbecf3fd5430921eaa3fe9054754f76d185 ]

RT tasks are allowed to dip below the min reserve but ALLOC_HARDER is
typically combined with ALLOC_MIN_RESERVE so RT tasks are a little
unusual.  While there is some justification for allowing RT tasks access
to memory reserves, there is a strong chance that a RT task that is also
under memory pressure is at risk of missing deadlines anyway.  Relax how
much reserves an RT task can access by treating it the same as __GFP_HIGH
allocations.

Note that in a future kernel release that the RT special casing will be
removed.  Hard realtime tasks should be locking down resources in advance
and ensuring enough memory is available.  Even a soft-realtime task like
audio or video live decoding which cannot jitter should be allocating both
memory and any disk space required up-front before the recording starts
instead of relying on reserves.  At best, reserve access will only delay
the problem by a very short interval.

Link: https://lkml.kernel.org/r/20230113111217.14134-3-mgorman@techsingularity.net
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: NeilBrown <neilb@suse.de>
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Stable-dep-of: 281dd25c1a01 ("mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic reserves")
Signed-off-by: Sasha Levin <sashal@kernel.org>
mm/page_alloc.c