Re: [Devel] Re: [PATCH] Show slab memory usage on OOM and SysRq-M (v3)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andrew Morton wrote:
> On Wed, 18 Apr 2007 11:13:01 +0400 Pavel Emelianov <[email protected]> wrote:
> 
> 
>>The out_of_memory() function and SysRq-M handler call
>>show_mem() to show the current memory usage state.
>>
>>This is also helpful to see which slabs are the largest
>>in the system.
>>
>>Thanks Pekka for good idea of how to make it better.
>>
>>The nr_pages is stored on kmem_list3 because:
>>
>>1. as Eric pointed out, we do not want to defeat 
>>   NUMA optimizations;
>>2. we do not need for additional LOCK-ed operation on
>>   altering this field - l3->list_lock is already taken
>>   where needed.
>>
>>Made naming more descriptive according to Dave.
>>
>>Signed-off-by: Pavel Emelianov <[email protected]>
>>Signed-off-by: Kirill Korotaev <[email protected]>
>>Acked-by: Pekka Enberg <[email protected]>
>>Cc: Eric Dumazet <[email protected]>
>>Cc: Dave Hansen <[email protected]>
>>
> 
> This is rather a lot of new code and even new locking.
> 
> Any time we actually need this what-the-heck-is-happening-in-slab info, the
> reporter is able to work out the problem via /proc/slabinfo.  Either by
> taking a look in there before the system dies completely, or by looking in
> there after the oom-killing.
the reality looks a bit differently (at least on machines overcommited with containers):
1. OOM can be unable to free enough memory for the system to do some
   real progress in some real-life situations. So you can't login and check.
2. People do not tend to monitor the logs and check the issue immeadeately when
   it happened. So having an information collected from the kernel is really helpfull.
   show_mem() does exactly the same on OOM.

So it is up to you, but I would suggest to commit.
Locking introduced here is simple and overhead-free on fast paths.

Thanks,
Kirill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux