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: <COL130-W536B434DEADC19798C2A9FBAFA0@phx.gbl>
Date:	Fri, 10 Apr 2015 04:16:15 +0000
From:	ZhangNeil <neilzhang1123@...mail.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2] mm: show free pages per each migrate type



----------------------------------------
> Date: Thu, 9 Apr 2015 13:47:01 -0700
> From: akpm@...ux-foundation.org
> To: neilzhang1123@...mail.com
> CC: linux-mm@...ck.org; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v2] mm: show free pages per each migrate type
>
> On Thu, 9 Apr 2015 10:19:10 +0800 Neil Zhang <neilzhang1123@...mail.com> 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
>
> Thanks. The proposed output does indeed look a lot better.
>
> The columns don't line up, but I guess we can live with that ;)
>

Thanks Andrew.

>
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -3327,7 +3313,7 @@ void show_free_areas(unsigned int filter)
>>
>> for_each_populated_zone(zone) {
>> unsigned long nr[MAX_ORDER], flags, order, total = 0;
>> - unsigned char types[MAX_ORDER];
>> + unsigned long nr_free[MAX_ORDER][MIGRATE_TYPES], mtype;
>>
>> if (skip_free_areas_node(filter, zone_to_nid(zone)))
>> continue;
>
> nr_free[][] is an 8x11 array of 8, I think? That's 704 bytes of stack,
> and show_free_areas() is called from very deep call stacks - from the
> oom-killer, for example. We shouldn't do this.
>
> I think we can eliminate nr_free[][]:

what about make it as global variable?

>
>> + for (mtype = 0; mtype < MIGRATE_TYPES; mtype++) {
>> + printk("%12s: ", migratetype_names[mtype]);
>> + for (order = 0; order < MAX_ORDER; order++)
>> + printk("%6lu ", nr_free[order][mtype]);
>> + printk("\n");
>> + }
>
> In the above loop, take zone->lock and calculate the nr_free for this
> particular order/mtype, then release zone->lock.
>
> That will be slower, but show_free_areas() doesn't need to be fast.

Yes, it mainly be called in oom killer.

Best Regards,
Neil Zhang

 		 	   		  --
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/