[PATCH] VM tuning patch, take 2

[PATCH] VM tuning patch, take 2

[Jonathan Morton]

>> >>For comparison, what was the time taken by -j15 build before your patch?
>> >
>> >Plain 2.4.5 gives 6m20s, but uses 190Mb of swap to achieve that - nearly 3
>> >times what my patched version does.  I could try adding more swap (on a
>> >faster device) and see what make -j 20 does...
>>
>> On plain 2.4.5 and a 1Gb swapfile located on an Ultra160 10000rpm device,
>> make -j 20 took 7m20s, peaking at 370Mb swap usage.  With the extra
>> patches, it takes 6m30, peaking at 254Mb swap usage.  Looks like the new
>> patches have a greater positive impact the higher the VM load.  :)
>
>From your numbers I have seen no regressions/negative impact, so right
>on :)

OK, the patch is now uploaded at:

http://www.chromatix.uklinux.net/linux-patches/vm-update-2.patch

I'd like people to go over it to make sure I've not boo-booed in some
SMP-incompatible way, then the guys with the big machines and workloads can
have a play.  It incorporates many if not most of the individual
improvements posted here, as well as some additions of my own, so I
strongly reccommend applying to a virgin 2.4.5 tree.

Enjoy!


--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)

The key to knowledge is not to rely on people to teach you it.

GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)


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

Re: [PATCH] VM tuning patch, take 2

[Marcelo Tosatti]

On Thu, 7 Jun 2001, Jonathan Morton wrote:

> >> >>For comparison, what was the time taken by -j15 build before your patch?
> >> >
> >> >Plain 2.4.5 gives 6m20s, but uses 190Mb of swap to achieve that - nearly 3
> >> >times what my patched version does.  I could try adding more swap (on a
> >> >faster device) and see what make -j 20 does...
> >>
> >> On plain 2.4.5 and a 1Gb swapfile located on an Ultra160 10000rpm device,
> >> make -j 20 took 7m20s, peaking at 370Mb swap usage.  With the extra
> >> patches, it takes 6m30, peaking at 254Mb swap usage.  Looks like the new
> >> patches have a greater positive impact the higher the VM load.  :)
> >
> >>From your numbers I have seen no regressions/negative impact, so right
> >on :)
> 
> OK, the patch is now uploaded at:
> 
> http://www.chromatix.uklinux.net/linux-patches/vm-update-2.patch
> 
> I'd like people to go over it to make sure I've not boo-booed in some
> SMP-incompatible way, then the guys with the big machines and workloads can
> have a play.  It incorporates many if not most of the individual
> improvements posted here, as well as some additions of my own, so I
> strongly reccommend applying to a virgin 2.4.5 tree.

-       free += (dentry_stat.nr_unused * sizeof(struct dentry)) >>PAGE_SHIFT;
-       free += (inodes_stat.nr_unused * sizeof(struct inode)) >> PAGE_SHIFT;
+       /* free += (dentry_stat.nr_unused * sizeof(struct dentry)) >> PAGE_SHIFT;
+          free += (inodes_stat.nr_unused * sizeof(struct inode)) >> PAGE_SHIFT;
+        */


On workloads full of dentries/inodes, allocations are going to fail with
this change (remember most dentries/inodes _are_ usually freeable). 

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

Re: [PATCH] VM tuning patch, take 2

[Marcelo Tosatti]

+               if ((gfp_mask & (__GFP_WAIT | __GFP_IO)) == (__GFP_WAIT | __GFP_IO)) {
+                       int progress = try_to_free_pages(gfp_mask);
+                       if(!progress) {
+                               wakeup_kswapd(1);
+                               goto try_again;
+                       }

You're going to allow GFP_BUFFER allocations to eat from the reserved
queues. Eek. 





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

Re: [PATCH] VM tuning patch, take 2

[Marcelo Tosatti]

On Fri, 8 Jun 2001, Jonathan Morton wrote:

> At 1:19 am +0100 8/6/2001, Marcelo Tosatti wrote:
> >+               if ((gfp_mask & (__GFP_WAIT | __GFP_IO)) == (__GFP_WAIT |
> >__GFP_IO)) {
> >+                       int progress = try_to_free_pages(gfp_mask);
> >+                       if(!progress) {
> >+                               wakeup_kswapd(1);
> >+                               goto try_again;
> >+                       }
> >
> >You're going to allow GFP_BUFFER allocations to eat from the reserved
> >queues. Eek.
> 
> Hang on, I did optimise that part - let me check it against your
> original...  but hey, it's the same behaviour!
> 
>                 if (gfp_mask & __GFP_WAIT) {
>                        int progress;
>                        if (gfp_mask & __GFP_IO) {
>                                 progress = try_to_free_pages(gfp_mask);
>                                 if (!progress) {
>                                         /*
>                                          * Not able to make progress freeing
>                                          * pages: wait for kswapd to free
>                                          * pages if possible.
>                                          */
>                                         if (gfp_mask & __GFP_IO) {
>                                                 wakeup_kswapd(1);
>                                                 goto try_again;
>                                         }
>                                 }
>                         }
>                 }
> 
> Can you point out why the behaviour of your code is *any* different from
> mine?  

It is not.

> Or have you just found a bug in your own code?  :)

Yes, my code is also broken. 

It should be: 

	progress = try_to_free_pages(gfp_mask);

	if (!progress) { 
		if (gfp_mask & __GFP_IO) { 
			wakeup_kswapd(1);
			goto try_again;
		} else 
			return NULL;
	} else
		goto try_again;


Also note that my code makes non-zero order allocations loop like mad
here. You may want to fix that, too. 


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

Re: [PATCH] VM tuning patch, take 2

[Jonathan Morton]

>-       free += (dentry_stat.nr_unused * sizeof(struct dentry)) >>PAGE_SHIFT;
>-       free += (inodes_stat.nr_unused * sizeof(struct inode)) >> PAGE_SHIFT;
>+       /* free += (dentry_stat.nr_unused * sizeof(struct dentry)) >>
>PAGE_SHIFT;
>+          free += (inodes_stat.nr_unused * sizeof(struct inode)) >>
>PAGE_SHIFT;
>+        */
>
>
>On workloads full of dentries/inodes, allocations are going to fail with
>this change (remember most dentries/inodes _are_ usually freeable).

OK.  I made that change to help bring vm_enough_memory() and
out_of_memory() in line with each other, so if we put that back in, it
needs to be put in out_of_memory() as well.

As it happens, the dentry and inode caches get shrunk under VM pressure,
and so by the time swap is full and buffers+cache are a minimum size, these
caches will normally also be shrunk to their furthest sensible extent.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)

The key to knowledge is not to rely on people to teach you it.

GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)


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

Re: [PATCH] VM tuning patch, take 2

[Ed Tomlinson]

On Thursday 07 June 2001 21:35, Jonathan Morton wrote:
> >-       free += (dentry_stat.nr_unused * sizeof(struct dentry))
> > >>PAGE_SHIFT; -       free += (inodes_stat.nr_unused * sizeof(struct
> > inode)) >> PAGE_SHIFT; +       /* free += (dentry_stat.nr_unused *
> > sizeof(struct dentry)) >> PAGE_SHIFT;
> >+          free += (inodes_stat.nr_unused * sizeof(struct inode)) >>
> >PAGE_SHIFT;
> >+        */
> >
> >
> >On workloads full of dentries/inodes, allocations are going to fail with
> >this change (remember most dentries/inodes _are_ usually freeable).
>
> OK.  I made that change to help bring vm_enough_memory() and
> out_of_memory() in line with each other, so if we put that back in, it
> needs to be put in out_of_memory() as well.
>
> As it happens, the dentry and inode caches get shrunk under VM pressure,
> and so by the time swap is full and buffers+cache are a minimum size, these
> caches will normally also be shrunk to their furthest sensible extent.

Think you are right Jonathan.  This adding this back is _not_ going to make a 
difference.  With the changes Rik made for 2.4.5, these caches are agressivily
shrunk when there is free shortage...

So far so good with take 2 here.

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

Re: [PATCH] VM tuning patch, take 2

[Jonathan Morton]

At 1:19 am +0100 8/6/2001, Marcelo Tosatti wrote:
>+               if ((gfp_mask & (__GFP_WAIT | __GFP_IO)) == (__GFP_WAIT |
>__GFP_IO)) {
>+                       int progress = try_to_free_pages(gfp_mask);
>+                       if(!progress) {
>+                               wakeup_kswapd(1);
>+                               goto try_again;
>+                       }
>
>You're going to allow GFP_BUFFER allocations to eat from the reserved
>queues. Eek.

Hang on, I did optimise that part - let me check it against your
original...  but hey, it's the same behaviour!

                if (gfp_mask & __GFP_WAIT) {
                       int progress;
                       if (gfp_mask & __GFP_IO) {
                                progress = try_to_free_pages(gfp_mask);
                                if (!progress) {
                                        /*
                                         * Not able to make progress freeing
                                         * pages: wait for kswapd to free
                                         * pages if possible.
                                         */
                                        if (gfp_mask & __GFP_IO) {
                                                wakeup_kswapd(1);
                                                goto try_again;
                                        }
                                }
                        }
                }

Can you point out why the behaviour of your code is *any* different from
mine?  Or have you just found a bug in your own code?  :)

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)

The key to knowledge is not to rely on people to teach you it.

GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)


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

Re: [PATCH] VM tuning patch, take 2

[Jonathan Morton]

>> Or have you just found a bug in your own code?  :)
>
>Yes, my code is also broken.
>
>It should be:
>
>	progress = try_to_free_pages(gfp_mask);
>
>	if (!progress) {
>		if (gfp_mask & __GFP_IO) {
>			wakeup_kswapd(1);
>			goto try_again;
>		} else
>			return NULL;
>	} else
>		goto try_again;
>
>
>Also note that my code makes non-zero order allocations loop like mad
>here. You may want to fix that, too.

Sorry, I don't have time to fix anything else today - I'm already pressed
for time on preparing a presentation for Philips Semiconductors (there's a
cash prize involved).  Explanation: I'm studying Computer Systems
Engineering, so I get to do Electronics as well as Computing.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)

The key to knowledge is not to rely on people to teach you it.

GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)


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

Re: [PATCH] VM tuning patch, take 2

[Rik van Riel]

On Thu, 7 Jun 2001, Ed Tomlinson wrote:

> Think you are right Jonathan.  This adding this back is _not_ going to
> make a difference.  With the changes Rik made for 2.4.5, these caches
> are agressivily shrunk when there is free shortage...

Suppose you have 80MB of free memory, 120MB in inode/dentry
cache and no swap.  A 100MB allocation will _fail_ with this
code removed from vm_enough_memory(), even though it's easy
to free the inode and dentry caches...

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

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