aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-sqlite.py
diff options
context:
space:
mode:
authorMichal Hocko <[email protected]>2020-10-13 16:56:07 -0700
committerLinus Torvalds <[email protected]>2020-10-13 18:38:33 -0700
commitab00db216c9c78cc0a68bc4e27889c1ee374598d (patch)
tree34fefdd25a96bc1c3f5a6ac9ea49d7e869d034c3 /tools/perf/scripts/python/export-to-sqlite.py
parente320d3012d25b1fb5f3df4edb7bd44a1c362ec10 (diff)
include/linux/gfp.h: clarify usage of GFP_ATOMIC in !preemptible contexts
There is a general understanding that GFP_ATOMIC/GFP_NOWAIT are to be used from atomic contexts. E.g. from within a spin lock or from the IRQ context. This is correct but there are some atomic contexts where the above doesn't hold. One of them would be an NMI context. Page allocator has never supported that and the general fear of this context didn't let anybody to actually even try to use the allocator there. Good, but let's be more specific about that. Another such a context, and that is where people seem to be more daring, is raw_spin_lock. Mostly because it simply resembles regular spin lock which is supported by the allocator and there is not any implementation difference with !RT kernels in the first place. Be explicit that such a context is not supported by the allocator. The underlying reason is that zone->lock would have to become raw_spin_lock as well and that has turned out to be a problem for RT (http://lkml.kernel.org/r/[email protected]). Signed-off-by: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Reviewed-by: Uladzislau Rezki <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/export-to-sqlite.py')
0 files changed, 0 insertions, 0 deletions