aboutsummaryrefslogtreecommitdiffstats
path: root/lib/test_printf.c
diff options
context:
space:
mode:
authorMel Gorman <[email protected]>2023-01-13 11:12:13 +0000
committerAndrew Morton <[email protected]>2023-02-03 06:33:12 +0000
commitc988dcbecf3fd5430921eaa3fe9054754f76d185 (patch)
tree8d5280e1747108a69163890cc244eadad2c63cc7 /lib/test_printf.c
parentmm/page_alloc: rename ALLOC_HIGH to ALLOC_MIN_RESERVE (diff)
downloadkernel-c988dcbecf3fd5430921eaa3fe9054754f76d185.tar.gz
kernel-c988dcbecf3fd5430921eaa3fe9054754f76d185.zip
mm/page_alloc: treat RT tasks similar to __GFP_HIGH
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/[email protected] Signed-off-by: Mel Gorman <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: NeilBrown <[email protected]> Cc: Thierry Reding <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
Diffstat (limited to 'lib/test_printf.c')
0 files changed, 0 insertions, 0 deletions