summaryrefslogtreecommitdiffstats
path: root/fs/notify/inotify
diff options
context:
space:
mode:
authorStephen Wilson <wilsons@start.ca>2011-05-24 17:12:49 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2011-05-25 08:39:35 -0700
commit5b52fc890bece77bffb9fade69239f71384ef02b (patch)
tree52848297984dba4c0f4106c5303a1a4bf0db92b0 /fs/notify/inotify
parentf2beb7983613ecca20a61604f01ab50cc7a797e6 (diff)
downloadop-kernel-dev-5b52fc890bece77bffb9fade69239f71384ef02b.zip
op-kernel-dev-5b52fc890bece77bffb9fade69239f71384ef02b.tar.gz
proc: allocate storage for numa_maps statistics once
In show_numa_map() we collect statistics into a numa_maps structure. Since the number of NUMA nodes can be very large, this structure is not a candidate for stack allocation. Instead of going thru a kmalloc()+kfree() cycle each time show_numa_map() is invoked, perform the allocation just once when /proc/pid/numa_maps is opened. Performing the allocation when numa_maps is opened, and thus before a reference to the target tasks mm is taken, eliminates a potential stalemate condition in the oom-killer as originally described by Hugh Dickins: ... imagine what happens if the system is out of memory, and the mm we're looking at is selected for killing by the OOM killer: while we wait in __get_free_page for more memory, no memory is freed from the selected mm because it cannot reach exit_mmap while we hold that reference. Signed-off-by: Stephen Wilson <wilsons@start.ca> Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Hugh Dickins <hughd@google.com> Cc: David Rientjes <rientjes@google.com> Cc: Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Christoph Lameter <cl@linux-foundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/notify/inotify')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud