From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx205.postini.com [74.125.245.205]) by kanga.kvack.org (Postfix) with SMTP id 2806A6B0002 for ; Sun, 12 May 2013 23:00:27 -0400 (EDT) References: <1310394396.24243.YahooMailNeo@web162006.mail.bf1.yahoo.com> <20110711145448.GI15285@suse.de> <1310462107.89450.YahooMailNeo@web162007.mail.bf1.yahoo.com> <20110712093510.GB7529@suse.de> <1310484381.60694.YahooMailNeo@web162011.mail.bf1.yahoo.com> <20110712154404.GD7529@suse.de> Message-ID: <1368414026.58026.YahooMailNeo@web160103.mail.bf1.yahoo.com> Date: Sun, 12 May 2013 20:00:26 -0700 (PDT) From: PINTU KUMAR Reply-To: PINTU KUMAR Subject: [Query] Performance degradation with memory compaction (on QC chip-set) In-Reply-To: <20110712154404.GD7529@suse.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1520606428-1686909767-1368414026=:58026" Sender: owner-linux-mm@kvack.org List-ID: To: Mel Gorman Cc: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" --1520606428-1686909767-1368414026=:58026 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear Mel Gorman,=0A=0AI have one question about memory compaction.=0AKernel= version: kernel-3.4 (ARM)=0AChipset: Qual-Comm MSM8930 dual-core.=0A=0AWe = wanted to enable CONFIG_COMPACTION for our product with kernel-3.4.=0ABut Q= C commented that, enabling compaction on their chip-set is causing performa= nce degradation for some streaming scenarios (from the beginning).=0A=0AI w= anted to know is this possible always?=0AWe used compaction with exynos pro= cessor and did not observe any performance degradation.=0A=0A=0AAll,=0ADoes= any one observed any performance problem (on any chipset) by enabling comp= action?=0A=0A=0APlease let me know your comments.=0AIt will be helpful to d= ecide on enabling compaction or not.=0A=0A=0AThank You.=0AWith Regards,=0AP= intu=0A=0A=0A=0A>________________________________=0A> From: Mel Gorman =0A>To: Pintu Agarwal =0A>Sent: Tues= day, 12 July 2011 8:44 AM=0A>Subject: Re: How to verify memory compaction o= n Kernel2.6.36??=0A> =0A>=0A>On Tue, Jul 12, 2011 at 08:26:21AM -0700, Pint= u Agarwal wrote:=0A>> =A0=0A>> Actually I enabled compaction without HUGETL= B support. Hope this is fine.=0A>> =A0=0A>=0A>In terms of compaction yes. I= n terms of your target application, I don't=0A>know.=0A>=0A>> Then I wrote = a sample kernel module to allocate physical pages using kmalloc.=0A>> (By p= assing the memory size from sample user space application and passing to th= is kernel module via ioctl calls)=0A>> =A0=0A>=0A>The allocations will not = be accessible to userspace without additional=0A>driver support to map the = pages in userspace.=0A>=0A>> Using these application, I request for total n= umber of physical pages of the desired order(from commandline of user app).= =0A>> And at the sametime verifying the buddyinfo before and after the allo= cation.=0A>> A sample output of my application is as follows:-=0A>> =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=0A>> /opt/pintu # ./app_pinchar.bin=0A>> Node 0, z= one=A0=A0 Normal=A0=A0=A0=A0 34=A0=A0=A0=A0=A0 9=A0=A0=A0=A0 13=A0=A0=A0=A0= =A0 7=A0=A0=A0=A0 11=A0=A0=A0=A0=A0 6=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0 2=A0= =A0=A0=A0=A0 3=A0=A0=A0=A0=A0 1=A0=A0=A0=A0 36=0A>> Node 0, zone=A0 HighMem= =A0=A0=A0=A0 53=A0=A0=A0 194=A0=A0=A0 110=A0=A0=A0=A0 36=A0=A0=A0=A0 21=A0= =A0=A0=A0=A0 7=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0 3=A0=A0=A0= =A0=A0 2=A0=A0=A0=A0=A0 6=0A>> Page block order: 10=0A>> Pages per block:= =A0 1024=0A>> Free pages count per migrate type at order=A0=A0=A0=A0=A0=A0 = 0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0 3=A0=A0=A0=A0=A0 4=A0=A0= =A0=A0=A0 5=A0=A0=A0=A0=A0 6=A0=A0=A0=A0=A0 7=A0=A0=A0=A0=A0 8=A0=A0=A0=A0= =A0 9=A0=A0=A0=A0 10=0A>> Node=A0=A0=A0 0, zone=A0=A0 Normal, type=A0=A0=A0= Unmovable=A0=A0=A0=A0 32=A0=A0=A0=A0=A0 5=A0=A0=A0=A0=A0 8=A0=A0=A0=A0=A0 = 5=A0=A0=A0=A0 11=A0=A0=A0=A0=A0 5=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0 0=A0=A0= =A0=A0=A0 2=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=0A>> Node=A0=A0=A0 0, zone=A0= =A0 Normal, type=A0 Reclaimable=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 2=A0=A0=A0= =A0=A0 4=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 = 0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 0=0A>> = Node=A0=A0=A0 0, zone=A0=A0 Normal, type=A0=A0=A0=A0=A0 Movable=A0=A0=A0=A0= =A0 1=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0= =A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 0=A0=A0= =A0=A0=A0 0=A0=A0=A0=A0 35=0A>> Node=A0=A0=A0 0, zone=A0=A0 Normal, type=A0= =A0=A0=A0=A0 Reserve=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0= =A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0= =A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 1=0A>> Node=A0=A0= =A0 0, zone=A0=A0 Normal, type=A0=A0=A0=A0=A0 Isolate=A0=A0=A0=A0=A0 0=A0= =A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0= =A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 = 0=A0=A0=A0=A0=A0 0=0A>> Node=A0=A0=A0 0, zone=A0 HighMem, type=A0=A0=A0 Unm= ovable=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0 3= =A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 1=A0=A0= =A0=A0=A0 2=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 1=0A>> Node=A0=A0=A0 0, zone=A0= HighMem, type=A0 Reclaimable=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0= =A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0= =A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=0A>> N= ode=A0=A0=A0 0, zone=A0 HighMem, type=A0=A0=A0=A0=A0 Movable=A0=A0=A0=A0 21= =A0=A0=A0 194=A0=A0=A0 108=A0=A0=A0=A0 33=A0=A0=A0=A0 20=A0=A0=A0=A0=A0 7= =A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 1=A0=A0= =A0=A0=A0 4=0A>> Node=A0=A0=A0 0, zone=A0 HighMem, type=A0=A0=A0=A0=A0 Rese= rve=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0= =A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0= =A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 1=0A>> Node=A0=A0=A0 0, zone=A0 Hi= ghMem, type=A0=A0=A0=A0=A0 Isolate=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0= =A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0= =A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0= =0A>> Number of blocks type=A0=A0=A0=A0 Unmovable=A0 Reclaimable=A0=A0=A0= =A0=A0 Movable=A0=A0=A0=A0=A0 Reserve=A0=A0=A0=A0=A0 Isolate=0A>> Node 0, z= one=A0=A0 Normal=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 82=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 4=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 73=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0=0A>> Node 0, zone=A0 HighMem=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 14=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 81=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 0=0A>> ----------------------------------------------------= ---------------------------------------=0A>> =A0=0A>> Enter the page order(= in power of 2) : 512=0A>=0A>Page order 512? That's a good trick. I assume y= ou means order 9 for 512=0A>pages.=0A>=0A>> Enter the number of such block = : 200=0A>> ERROR : ioctl - PINCHAR_ALLOC - Failed, after block num =3D 72 != !!=0A>> DONE.....=0A>> =0A>=0A>72 corresponds almost exactly to the number = of order-9 pages that were=0A>free when the application started.=0A>=0A>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A>> Node 0, zone=A0=A0 Norma= l=A0=A0=A0 100=A0=A0=A0=A0 84=A0=A0=A0=A0 53=A0=A0=A0=A0 36=A0=A0=A0=A0 33= =A0=A0=A0=A0 21=A0=A0=A0=A0=A0 8=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 3=A0=A0=A0= =A0=A0 2=A0=A0=A0=A0=A0 0=0A>> Node 0, zone=A0 HighMem=A0=A0=A0 844=A0=A0= =A0 744=A0=A0=A0 612=A0=A0=A0 357=A0=A0=A0 200=A0=A0=A0=A0 91=A0=A0=A0=A0= =A0 8=A0=A0=A0=A0=A0 3=A0=A0=A0=A0=A0 4=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0 6= =0A>> =0A>=0A>There is almost no free memory in the Normal zone at this sta= ge of=0A>the test implying that even perfect compaction of all pages would= =0A>still not result in a new order-9 page while obeying watermarks.=0A>=0A= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A>> =A0=0A>> Then I want to verify wheth= er compaction is working for the all allocation request or not.=0A>=0A>Read= /proc/vmstat but I doubt it was used much. Memory was mostly=0A>unfragment= ed when the application started. It is likely that after=0A>72 order-9 page= s there was not enough free memory to compact further=0A>and that is why th= e allocation failed.=0A>=0A>> OR, at least how far compaction is helpful in= these scenarios.=0A>> =A0=0A>=0A>Compaction would have been helpful in the= event the system has been=0A>running for some time and was fragmented. Thi= s test looks like it=0A>happened very close to boot so compaction would not= have been requried.=0A>=0A>> Please let me know how compaction can be effe= ctive in such cases where order 8,9,10 pages are requested.=0A>> =A0=0A>=0A= >Compaction reduces allocation latencies when memory is fragmented for=0A>h= igh-order allocations like this. I'm not what else you are expecting=0A>to = hear.=0A>=0A>-- =0A>Mel Gorman=0A>SUSE Labs=0A>=0A>=0A> --1520606428-1686909767-1368414026=:58026 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Mel Gorman,

I have one question about memory compaction.
<= div>Kernel version: kernel-3.4 (ARM)
Chipset: Qual-Comm MSM8930 d= ual-core.

We wanted to enable CONFIG_COMPACTION fo= r our product with kernel-3.4.
But QC commented that, enabling co= mpaction on their chip-set is causing performance degradation for some stre= aming scenarios (from the beginning).

I wanted to = know is this possible always?
We used compaction with exynos proc= essor and did not observe any performance degradation.

=

All,
Does any one observed any performance pr= oblem (on any chipset) by enabling compaction?

Please let me know your comments.
It will be helpful to decide on enabling compaction or not.

=
Thank You.
With Regards,
Pintu

<= div dir=3D"ltr">
From: Mel Gorman <mgorman@suse.d= e>
To: Pintu Agarwa= l <pintu_agarwal@yahoo.com>
Subject: Re: How to verify memory compaction on Kernel2.6.36??

On Tu= e, Jul 12, 2011 at 08:26:21AM -0700, Pintu Agarwal wrote:
>  > Actually I enabled compaction without HUGETLB support. Hope this is f= ine.
>  

In terms of compaction yes. In terms of your tar= get application, I don't
know.

> Then I wrote a sample kernel = module to allocate physical pages using kmalloc.
> (By passing the me= mory size from sample user space application and passing to this kernel mod= ule via ioctl calls)
>  

The allocations will not be acce= ssible to userspace without additional
driver support to map the pages i= n userspace.

> Using these application, I request for total numbe= r of physical pages of the desired order(from commandline of user app).
= > And at the sametime verifying the buddyinfo before and after the alloc= ation.
> A sample output of my application is as follows:-
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> /opt/pintu # ./= app_pinchar.bin
> Node 0, zone   Normal   &n= bsp; 34      9     13 &nb= sp;    7     11    &= nbsp; 6      2      2&nbs= p;     3      1  &nb= sp;  36
> Node 0, zone  HighMem     53&= nbsp;   194    110     36 = ;    21      7   &nb= sp;  1      2      3=       2      6
> Pa= ge block order: 10
> Pages per block:  1024
> Free pages c= ount per migrate type at order       0      = 1      2      3 &nbs= p;    4      5   &nb= sp;  6      7      8=       9     10
> Node&nb= sp;   0, zone   Normal, type    Unmovabl= e     32      5  &nb= sp;   8      5     1= 1      5      2 &nbs= p;    0      2   &nb= sp;  0      0
> Node    = 0, zone   Normal, type  Reclaimable    &= nbsp; 1      2      4      2 &nb= sp;    0      0   &n= bsp;  0      1      = 1      1      0
> N= ode    0, zone   Normal, type   &nb= sp;  Movable      1    &n= bsp; 0      1      0 = ;     0      1  &nbs= p;   0      1    &nb= sp; 0      0     35
> No= de    0, zone   Normal, type   &nbs= p;  Reserve      0    &nb= sp; 0      0      0      0      0 &nb= sp;    0      0   &n= bsp;  0      0      = 1
> Node    0, zone   Normal, type &nbs= p;    Isolate      0  &nb= sp;   0      0    &n= bsp; 0      0      0 = ;     0      0  &nbs= p;   0      0    &nb= sp; 0
> Node    0, zone  HighMem, type  = ;  Unmovable      1    &n= bsp; 0      2      3 = ;     1      0      0      1 &nb= sp;    2      1   &n= bsp;  1
> Node    0, zone  HighMem, type&nbs= p; Reclaimable      0     = ; 0      0      0 &n= bsp;    0      0   &= nbsp;  0      0     = 0      0      0
> = Node    0, zone  HighMem, type    &= nbsp; Movable     21    194  &= nbsp; 108     33     20  =     7      1    = ;  1      1      1      4
> = Node    0, zone  HighMem, type    &= nbsp; Reserve      0     = 0      0      0 &nb= sp;    0      0   &n= bsp;  0      0      = 0      0      1
> N= ode    0, zone  HighMem, type    &n= bsp; Isolate      0      = 0      0      0 &nbs= p;    0      0   &nb= sp;  0      0      0=       0      0
> Number of blocks type     Unmovable  Re= claimable      Movable    &nbs= p; Reserve      Isolate
> Node 0, zone =   Normal           8= 2            4 =           73   =          1    &= nbsp;       0
> Node 0, zone  High= Mem           14 &nb= sp;          0  &nbs= p;        81    &nbs= p;       1      = ;      0
> --------------------------------------------------------------------------= -----------------
>  
> Enter the page order(in power of 2= ) : 512

Page order 512? That's a good trick. I assume you means orde= r 9 for 512
pages.

> Enter the number of such block : 200
&= gt; ERROR : ioctl - PINCHAR_ALLOC - Failed, after block num =3D 72 !!!
&= gt; DONE.....
>

72 corresponds almost exactly to the number o= f order-9 pages that were
free when the application started.

>= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Node 0, zone =   Normal    100     84  &= nbsp;  53     36     33 &= nbsp;   21      8    = ;  0      3      2      0
> Node 0, zone  HighMem =    844    744    612  &nb= sp; 357    200     91   &= nbsp;  8      3     = 4      1      6
> =

There is almost no free memory in the Normal zone at this stage of<= br>the test implying that even perfect compaction of all pages would
sti= ll not result in a new order-9 page while obeying watermarks.

> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>  
> Then I want to verify= whether compaction is working for the all allocation request or not.
Read /proc/vmstat but I doubt it was used much. Memory was mostly
unfr= agmented when the application started. It is likely that after
72 order-= 9 pages there was not enough free memory to compact further
and that is why the allocation failed.
> OR, at least how far compaction is helpful in these scenarios.
>= ;  

Compaction would have been helpful in the event the system = has been
running for some time and was fragmented. This test looks like = it
happened very close to boot so compaction would not have been requrie= d.

> Please let me know how compaction can be effective in such c= ases where order 8,9,10 pages are requested.
>  

Compacti= on reduces allocation latencies when memory is fragmented for
high-order= allocations like this. I'm not what else you are expecting
to hear.
=
--
Mel Gorman
SUSE Labs


--1520606428-1686909767-1368414026=:58026-- -- 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/ . Don't email: email@kvack.org