| 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
| ||
|
Message-ID: <op.vtvuf5sk3l0zgt@mnazarewicz-glaptop> Date: Wed, 13 Apr 2011 17:25:08 +0200 From: "Michal Nazarewicz" <mina86@...a86.com> To: Américo Wang <xiyou.wangcong@...il.com>, "Pintu Agarwal" <pintu_agarwal@...oo.com> Cc: "Andrew Morton" <akpm@...ux-foundation.org>, "Eric Dumazet" <eric.dumazet@...il.com>, "Changli Gao" <xiaosuo@...il.com>, "Jiri Slaby" <jslaby@...e.cz>, azurIt <azurit@...ox.sk>, linux-kernel@...r.kernel.org, linux-mm@...ck.org, linux-fsdevel@...r.kernel.org, "Jiri Slaby" <jirislaby@...il.com> Subject: Re: Regarding memory fragmentation using malloc.... On Wed, 13 Apr 2011 15:56:00 +0200, Pintu Agarwal <pintu_agarwal@...oo.com> wrote: > My requirement is, I wanted to measure memory fragmentation level in > linux kernel2.6.29 (ARM cortex A8 without swap). > How can I measure fragmentation level(percentage) from /proc/buddyinfo ? [...] > In my linux2.6.29 ARM machine, the initial /proc/buddyinfo shows the > following: > Node 0, zone DMA 17 22 1 1 0 1 > 1 0 0 0 0 0 > Node 1, zone DMA 15 320 423 225 97 26 > 1 0 0 0 0 0 > > After running my sample program (with 16 iterations) the buddyinfo > output is as follows: > Requesting <16> blocks of memory of block size <262144>........ > Node 0, zone DMA 17 22 1 1 0 1 > 1 0 0 0 0 0 > Node 1, zone DMA 15 301 419 224 96 27 > 1 0 0 0 0 0 > nr_free_pages 169 > nr_free_pages 6545 > ***************************************** > > > Node 0, zone DMA 17 22 1 1 0 1 > 1 0 0 0 0 0 > Node 1, zone DMA 18 2 305 226 96 27 > 1 0 0 0 0 0 > nr_free_pages 169 > nr_free_pages 5514 > ----------------------------------------- > > The requested block size is 64 pages (2^6) for each block. > But if we see the output after 16 iterations the buddyinfo allocates > pages only from Node 1 , (2^0, 2^1, 2^2, 2^3). > But the actual allocation should happen from (2^6) block in buddyinfo. No. When you call malloc() only virtual address space is allocated. The actual allocation of physical space occurs when user space accesses the memory (either reads or writes) and it happens page at a time. As a matter of fact, if you have limited number of 0-order pages and allocates in user space block of 64 pages later accessing the memory, what really happens is that kernel allocates the 0-order pages and when it runs out of those, splits a 1-order page into two 0-order pages and takes one of those. Because of MMU, fragmentation of physical memory is not an issue for normal user space programs. It becomes an issue once you deal with hardware that does not have MMU nor support for scatter-getter DMA or with some big kernel structures. /proc/buddyinfo tells you how many free pages of given order there are in the system. You may interpret it in such a way that the bigger number of the low order pages the bigger fragmentation of physical memory. If there was no fragmentation (for some definition of the term) you'd get only the highest order pages and at most one page for each lower order. Again though, this fragmentation is not an issue for user space programs. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michal "mina86" Nazarewicz (o o) ooo +-----<email/xmpp: mnazarewicz@...gle.com>-----ooO--(_)--Ooo-- -- 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/
Powered by blists - more mailing lists