linux-kernel - Re: [PATCH v2] mm: show free pages per each migrate type

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.10.1504101944440.9879@chino.kir.corp.google.com>
Date:	Fri, 10 Apr 2015 19:50:07 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Neil Zhang <neilzhang1123@...mail.com>
cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH v2] mm: show free pages per each migrate type

On Thu, 9 Apr 2015, Neil Zhang wrote:

> show detailed free pages per each migrate type in show_free_areas.
> 
> After apply this patch, the log printed out will be changed from
> 
> [   558.212844@0] Normal: 218*4kB (UEMC) 207*8kB (UEMC) 126*16kB (UEMC) 21*32kB (UC) 5*64kB (C) 3*128kB (C) 1*256kB (C) 1*512kB (C) 0*1024kB 0*2048kB 1*4096kB (R) = 10784kB
> [   558.227840@0] HighMem: 3*4kB (UMR) 3*8kB (UMR) 2*16kB (UM) 3*32kB (UMR) 0*64kB 1*128kB (M) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 548kB
> 
> to
> 
> [   806.506450@1] Normal: 8969*4kB 4370*8kB 2*16kB 3*32kB 2*64kB 3*128kB 3*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 74804kB
> [   806.517456@1]       orders:      0      1      2      3      4      5      6      7      8      9     10
> [   806.527077@1]    Unmovable:   8287   4370      0      0      0      0      0      0      0      0      0
> [   806.536699@1]  Reclaimable:    681      0      0      0      0      0      0      0      0      0      0
> [   806.546321@1]      Movable:      1      0      0      0      0      0      0      0      0      0      0
> [   806.555942@1]      Reserve:      0      0      2      3      2      3      3      1      0      1      0
> [   806.565564@1]          CMA:      0      0      0      0      0      0      0      0      0      0      0
> [   806.575187@1]      Isolate:      0      0      0      0      0      0      0      0      0      0      0
> [   806.584810@1] HighMem: 80*4kB 15*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 440kB
> [   806.595383@1]       orders:      0      1      2      3      4      5      6      7      8      9     10
> [   806.605004@1]    Unmovable:     12      0      0      0      0      0      0      0      0      0      0
> [   806.614626@1]  Reclaimable:      0      0      0      0      0      0      0      0      0      0      0
> [   806.624248@1]      Movable:     11     15      0      0      0      0      0      0      0      0      0
> [   806.633869@1]      Reserve:     57      0      0      0      0      0      0      0      0      0      0
> [   806.643491@1]          CMA:      0      0      0      0      0      0      0      0      0      0      0
> [   806.653113@1]      Isolate:      0      0      0      0      0      0      0      0      0      0      0
> 
> Signed-off-by: Neil Zhang <neilzhang1123@...mail.com>

Sorry, this is just way too verbose.  This output is emitted to the kernel 
log on oom kill and since we lack a notification mechanism on system oom, 
the _only_ way for userspace to detect oom kills that have occurred is by 
scraping the kernel log.  This is exactly what we do, and we have missed 
oom kill events because they scroll from the ring buffer due to excessive 
output such as this, which is why output was limited with the 
show_free_areas() filter in the first place.  Just because oom kill output 
is much less than it has been in the past, for precisely this reason, 
doesn't mean we can make it excessive again.

So nack on this patch, and if we really need to have this information (I 
don't know your motivation for adding it since you list none in your 
changelog), then we need to consider an oom verbosity sysctl or, better, 
an actual system oom notification to userspace based on eventfd() without 
requiring memcg.
--
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/