All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michal Nazarewicz" <mina86@mina86.com>
To: "Américo Wang" <xiyou.wangcong@gmail.com>,
	"Pintu Agarwal" <pintu_agarwal@yahoo.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	"Eric Dumazet" <eric.dumazet@gmail.com>,
	"Changli Gao" <xiaosuo@gmail.com>, "Jiri Slaby" <jslaby@suse.cz>,
	azurIt <azurit@pobox.sk>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org, "Jiri Slaby" <jirislaby@gmail.com>
Subject: Re: Regarding memory fragmentation using malloc....
Date: Wed, 13 Apr 2011 17:25:08 +0200	[thread overview]
Message-ID: <op.vtvuf5sk3l0zgt@mnazarewicz-glaptop> (raw)
In-Reply-To: <112566.51053.qm@web162019.mail.bf1.yahoo.com>

On Wed, 13 Apr 2011 15:56:00 +0200, Pintu Agarwal  
<pintu_agarwal@yahoo.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@google.com>-----ooO--(_)--Ooo--

WARNING: multiple messages have this Message-ID (diff)
From: "Michal Nazarewicz" <mina86@mina86.com>
To: "Américo Wang" <xiyou.wangcong@gmail.com>,
	"Pintu Agarwal" <pintu_agarwal@yahoo.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Changli Gao <xiaosuo@gmail.com>, Jiri Slaby <jslaby@suse.cz>,
	azurIt <azurit@pobox.sk>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org, Jiri Slaby <jirislaby@gmail.com>
Subject: Re: Regarding memory fragmentation using malloc....
Date: Wed, 13 Apr 2011 17:25:08 +0200	[thread overview]
Message-ID: <op.vtvuf5sk3l0zgt@mnazarewicz-glaptop> (raw)
In-Reply-To: <112566.51053.qm@web162019.mail.bf1.yahoo.com>

On Wed, 13 Apr 2011 15:56:00 +0200, Pintu Agarwal  
<pintu_agarwal@yahoo.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@google.com>-----ooO--(_)--Ooo--

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-04-13 15:25 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-15 13:25 Regression from 2.6.36 azurIt
2011-03-17  0:15 ` Greg KH
2011-03-17  0:53   ` Dave Jones
2011-03-17 13:30     ` azurIt
2011-04-07 10:01   ` azurIt
2011-04-07 10:19     ` Jiri Slaby
2011-04-07 10:19       ` Jiri Slaby
2011-04-07 10:19       ` Jiri Slaby
2011-04-07 11:21       ` Américo Wang
2011-04-07 11:21         ` Américo Wang
2011-04-07 11:57         ` Eric Dumazet
2011-04-07 11:57           ` Eric Dumazet
2011-04-07 11:57           ` Eric Dumazet
2011-04-07 12:13           ` Eric Dumazet
2011-04-07 12:13             ` Eric Dumazet
2011-04-07 12:13             ` Eric Dumazet
2011-04-07 15:27             ` Changli Gao
2011-04-07 15:36               ` Eric Dumazet
2011-04-07 15:36                 ` Eric Dumazet
2011-04-07 15:36                 ` Eric Dumazet
2011-04-12 22:49                 ` Andrew Morton
2011-04-12 22:49                   ` Andrew Morton
2011-04-13  1:23                   ` Changli Gao
2011-04-13  1:23                     ` Changli Gao
2011-04-13  1:31                     ` Andrew Morton
2011-04-13  1:31                       ` Andrew Morton
2011-04-13  2:37                       ` Eric Dumazet
2011-04-13  2:37                         ` Eric Dumazet
2011-04-13  2:37                         ` Eric Dumazet
2011-04-13  6:54                         ` Regarding memory fragmentation using malloc Pintu Agarwal
2011-04-13  6:54                           ` Pintu Agarwal
2011-04-13 11:44                           ` Américo Wang
2011-04-13 11:44                             ` Américo Wang
2011-04-13 13:56                             ` Pintu Agarwal
2011-04-13 13:56                               ` Pintu Agarwal
2011-04-13 15:25                               ` Michal Nazarewicz [this message]
2011-04-13 15:25                                 ` Michal Nazarewicz
2011-04-14  6:44                                 ` Pintu Agarwal
2011-04-14  6:44                                   ` Pintu Agarwal
2011-04-14 10:47                                   ` Michal Nazarewicz
2011-04-14 10:47                                     ` Michal Nazarewicz
2011-04-14 12:24                                     ` Pintu Agarwal
2011-04-14 12:24                                       ` Pintu Agarwal
2011-04-14 12:31                                       ` Michal Nazarewicz
2011-04-14 12:31                                         ` Michal Nazarewicz
2011-04-13 21:16                         ` Regression from 2.6.36 Andrew Morton
2011-04-13 21:16                           ` Andrew Morton
2011-04-13 21:24                           ` Andrew Morton
2011-04-13 21:24                           ` Andrew Morton
2011-04-13 21:24                             ` Andrew Morton
2011-04-19 19:29                             ` azurIt
2011-04-19 19:29                               ` azurIt
2011-04-19 19:55                               ` Andrew Morton
2011-04-19 19:55                                 ` Andrew Morton
2011-04-13 21:44                           ` David Rientjes
2011-04-13 21:44                             ` David Rientjes
2011-04-13 21:54                             ` Andrew Morton
2011-04-13 21:54                               ` Andrew Morton
2011-04-14  2:10                           ` Eric Dumazet
2011-04-14  2:10                             ` Eric Dumazet
2011-04-14  2:10                             ` Eric Dumazet
2011-04-14  5:28                             ` Andrew Morton
2011-04-14  5:28                               ` Andrew Morton
2011-04-14  6:31                               ` Eric Dumazet
2011-04-14  6:31                                 ` Eric Dumazet
2011-04-14  6:31                                 ` Eric Dumazet
2011-04-14  9:08                                 ` azurIt
2011-04-14  9:08                                   ` azurIt
2011-04-14 10:27                                   ` Eric Dumazet
2011-04-14 10:27                                     ` Eric Dumazet
2011-04-14 10:27                                     ` Eric Dumazet
2011-04-14 10:31                                     ` azurIt
2011-04-14 10:31                                       ` azurIt
2011-04-14 10:31                                       ` azurIt
2011-04-14 10:25                           ` Mel Gorman
2011-04-15  9:59                             ` azurIt
2011-04-15  9:59                               ` azurIt
2011-04-15  9:59                               ` azurIt
2011-04-15 10:47                               ` Mel Gorman
2011-04-15 10:47                                 ` Mel Gorman
2011-04-15 10:56                                 ` azurIt
2011-04-15 10:56                                   ` azurIt
2011-04-15 10:56                                   ` azurIt
2011-04-15 11:17                                   ` Mel Gorman
2011-04-15 11:17                                     ` Mel Gorman
2011-04-15 11:36                                     ` azurIt
2011-04-15 11:36                                       ` azurIt
2011-04-15 11:36                                       ` azurIt
2011-04-15 13:01                                       ` Mel Gorman
2011-04-15 13:01                                         ` Mel Gorman
2011-04-15 13:21                                         ` azurIt
2011-04-15 13:21                                           ` azurIt
2011-04-15 13:21                                           ` azurIt
2011-04-15 14:15                                           ` Mel Gorman
2011-04-15 14:15                                             ` Mel Gorman
2011-04-08 12:25               ` azurIt
2011-04-08 12:25                 ` azurIt
2011-04-08 12:25                 ` azurIt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=op.vtvuf5sk3l0zgt@mnazarewicz-glaptop \
    --to=mina86@mina86.com \
    --cc=akpm@linux-foundation.org \
    --cc=azurit@pobox.sk \
    --cc=eric.dumazet@gmail.com \
    --cc=jirislaby@gmail.com \
    --cc=jslaby@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pintu_agarwal@yahoo.com \
    --cc=xiaosuo@gmail.com \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.