linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pintu Agarwal <pintu_agarwal@yahoo.com>
To: "Américo Wang" <xiyou.wangcong@gmail.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 06:56:00 -0700 (PDT)	[thread overview]
Message-ID: <112566.51053.qm@web162019.mail.bf1.yahoo.com> (raw)
In-Reply-To: <BANLkTi=7KHMA_JOwQcMQj5M+XU=qO07s2g@mail.gmail.com>

Hi,

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 ?

Example : After each page allocation operation, I need to measure fragmentation level. If the level is above 80%, I will trigger a OOM or something to the user.
How can I reproduce this memory fragmentation scenario using a sample program?

Here is my sample program: (to check page allocation using malloc)
----------------------------------------------
#include<stdio.h>
#include<stdlib.h>
#include<string.h>
#include<errno.h>
#include<unistd.h>


#define PAGE_SIZE       (4*1024)

#define MEM_BLOCK       (64*PAGE_SIZE)


#define MAX_LIMIT       (16)

int main()
{
        char *ptr[MAX_LIMIT+1] = {NULL,};
        int i = 0;

        printf("Requesting <%d> blocks of memory of block size <%d>........\n",MAX_LIMIT,MEM_BLOCK);
        system("cat /proc/buddyinfo");
        system("cat /proc/zoneinfo | grep free_pages");
        printf("*****************************************\n\n\n");
        for(i=0; i<MAX_LIMIT; i++)
        {
                ptr[i] = (char *)malloc(sizeof(char)*MEM_BLOCK);
                if(ptr[i] == NULL)
                {
                        printf("ERROR : malloc failed(counter %d) <%s>\n",i,strerror(errno));
                        system("cat /proc/buddyinfo");
                        system("cat /proc/zoneinfo | grep free_pages");
                        printf("press any key to terminate......");
                        getchar();
                        exit(0);
                }
                memset(ptr[i],1,MEM_BLOCK);
                sleep(1);
                //system("cat /proc/buddyinfo");
                //system("cat /proc/zoneinfo | grep free_pages");
                //printf("-----------------------------------------\n");
        }

        sleep(1);
        system("cat /proc/buddyinfo");
        system("cat /proc/zoneinfo | grep free_pages");
        printf("-----------------------------------------\n");

        printf("press any key to end......");
        getchar();

        for(i=0; i<MAX_LIMIT; i++)
        {
                if(ptr[i] != NULL)
                {
                        free(ptr[i]);
                }
        }

        printf("DONE !!!\n");

        return 0;
}
EACH BLOCK SIZE = 64 Pages ==> (64 * 4 * 1024)
TOTAL BLOCKS = 16
----------------------------------------------
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.

Questions:
1) How to analyse buddyinfo based on each page block size?
2) How and in what scenario the buddyinfo changes?
3) Can we rely completely on buddyinfo information for measuring the level of fragmentation?

Can somebody through some more lights on this???

Thanks,
Pintu

--- On Wed, 4/13/11, Américo Wang <xiyou.wangcong@gmail.com> wrote:

> From: Américo Wang <xiyou.wangcong@gmail.com>
> Subject: Re: Regarding memory fragmentation using malloc....
> To: "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>
> Date: Wednesday, April 13, 2011, 6:44 AM
> On Wed, Apr 13, 2011 at 2:54 PM,
> Pintu Agarwal <pintu_agarwal@yahoo.com>
> wrote:
> > Dear All,
> >
> > I am trying to understand how memory fragmentation
> occurs in linux using many malloc calls.
> > I am trying to reproduce the page fragmentation
> problem in linux 2.6.29.x on a linux mobile(without Swap)
> using a small malloc(in loop) test program of BLOCK_SIZE
> (64*(4*K)).
> > And then monitoring the page changes in
> /proc/buddyinfo after each operation.
> > From the output I can see that the page values under
> buddyinfo keeps changing. But I am not able to relate these
> changes with my malloc BLOCK_SIZE.
> > I mean with my BLOCK_SIZE of (2^6 x 4K ==> 2^6
> PAGES) the 2^6 th block under /proc/buddyinfo should change.
> But this is not the actual behaviour.
> > Whatever is the blocksize, the buddyinfo changes only
> for 2^0 or 2^1 or 2^2 or 2^3.
> >
> > I am trying to measure the level of fragmentation
> after each page allocation.
> > Can somebody explain me in detail, how actually
> /proc/buddyinfo changes after each allocation and
> deallocation.
> >
> 
> What malloc() sees is virtual memory of the process, while
> buddyinfo
> shows physical memory pages.
> 
> When you malloc() 64K memory, the kernel may not allocate a
> 64K
> physical memory at one time
> for you.
> 
> Thanks.
> 


      

  reply	other threads:[~2011-04-13 14:02 UTC|newest]

Thread overview: 45+ 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 11:21       ` Américo Wang
2011-04-07 11:57         ` 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-12 22:49                 ` Andrew Morton
2011-04-13  1:23                   ` Changli Gao
2011-04-13  1:31                     ` Andrew Morton
2011-04-13  2:37                       ` Eric Dumazet
2011-04-13  6:54                         ` Regarding memory fragmentation using malloc Pintu Agarwal
2011-04-13 11:44                           ` Américo Wang
2011-04-13 13:56                             ` Pintu Agarwal [this message]
2011-04-13 15:25                               ` Michal Nazarewicz
2011-04-14  6:44                                 ` Pintu Agarwal
2011-04-14 10:47                                   ` Michal Nazarewicz
2011-04-14 12:24                                     ` Pintu Agarwal
2011-04-14 12:31                                       ` Michal Nazarewicz
2011-04-13 21:16                         ` Regression from 2.6.36 Andrew Morton
2011-04-13 21:24                           ` Andrew Morton
2011-04-19 19:29                             ` azurIt
2011-04-19 19:55                               ` Andrew Morton
2011-04-13 21:44                           ` David Rientjes
2011-04-13 21:54                             ` Andrew Morton
2011-04-14  2:10                           ` Eric Dumazet
2011-04-14  5:28                             ` Andrew Morton
2011-04-14  6:31                               ` Eric Dumazet
2011-04-14  9:08                                 ` azurIt
2011-04-14 10:27                                   ` Eric Dumazet
2011-04-14 10:31                                     ` azurIt
2011-04-14 10:25                           ` Mel Gorman
2011-04-15  9:59                             ` azurIt
2011-04-15 10:47                               ` Mel Gorman
2011-04-15 10:56                                 ` azurIt
2011-04-15 11:17                                   ` Mel Gorman
2011-04-15 11:36                                     ` azurIt
2011-04-15 13:01                                       ` Mel Gorman
2011-04-15 13:21                                         ` azurIt
2011-04-15 14:15                                           ` Mel Gorman
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=112566.51053.qm@web162019.mail.bf1.yahoo.com \
    --to=pintu_agarwal@yahoo.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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).