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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 23 Apr 2007 12:12:09 +0400
From:	Kirill Korotaev <dev@...ru>
To:	Andrew Morton <akpm@...l.org>
CC:	Pavel Emelianov <xemul@...ru>, dev@...nvz.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Eric Dumazet <dada1@...mosbay.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Dave Hansen <hansendc@...ibm.com>
Subject: Re: [Devel] Re: [PATCH] Show slab memory usage on OOM and SysRq-M
 (v3)

Andrew Morton wrote:
> On Wed, 18 Apr 2007 11:13:01 +0400 Pavel Emelianov <xemul@...ru> 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 <xemul@...nvz.org>
>>Signed-off-by: Kirill Korotaev <dev@...nvz.org>
>>Acked-by: Pekka Enberg <penberg@...helsinki.fi>
>>Cc: Eric Dumazet <dada1@...mosbay.com>
>>Cc: Dave Hansen <hansendc@...ibm.com>
>>
> 
> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/