Re: [RFC][PATCH -mm 2/2] mm: make shrink_all_memory try harder

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Rafael J. Wysocki" <[email protected]> wrote:
>
> On Tuesday 28 February 2006 04:25, Andrew Morton wrote:
> > "Rafael J. Wysocki" <[email protected]> wrote:
> > >
> > > Make shrink_all_memory() repeat the attempts to free more memory if there
> > > seems to be no pages to free.
> > > 
> > 
> > This description doesn't describe what the problem is, not how the patch
> > fixes it.  So I'm kinda left guessing.
> 
> I have described it in the 0/0 message, but I should have repeated that in the
> changelog, sorry.

Actually these [patch 0/n] emails are a nuisance - some poor schmuck just
has to copy-n-paste that text into the fist patch's changelog anwyay.

> > swsusp should call drop_pagecache() and then drop_slab() before trying to
> > use shrink_all_memory(), btw.
> 
> Well, sometimes we don't need to free a lot of memory.

OK.  But if clean pagecache and reclaimable slabs are left in memory,
they'll have to be written to swap, won't they?

It could well be more efficent to restore them from swap.  Slower suspend,
faster resume.

> > +	if (retry-- && ret < nr_pages) {
> > +		blk_congestion_wait(WRITE, HZ/5);
> > +		goto repeat;
> > +	}
> 
> I'd like to do this only if ret is 0.

Well I figured that this was a more general approach: we were _asked_ to
free that many pages.  If we haven't done that yet, keep trying.  Can you
test that code please?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux