Re: Good way to free as much memory as possible under 2.5.34?

[Andrew Morton <akpm@digeo.com>]

Pavel Machek wrote:
> 
> Hi!
> 
> > > > Allocating memory is pain because I have to free it afterwards. Yep I
> > > > have such code, but it is ugly. try_to_free_pages() really seems like
> > > > cleaner solution to me... if you only tell me how to fix it :-).
> > >
> > > "Fixing" the VM just so it behaves the way swsuspend wants is
> > > out. If swsuspend relies on all other subsystems playing nicely,
> > > I think it should be removed from the kernel.
> > >
> >
> > Yup.  Martin Bligh is cooking up a multi-page allocation API, so when that's
> > in place, swsusp need only do:
> >
> >       LIST_HEAD(foo);
> >       alloc_many_pages(&foo, nr_pages, __GFP_HIGHMEM|__GFP_WAIT);
> >       free_many_pages(&foo);
> >
> > So I suggest you do something local for the while, plan to use that later.
> >
> > (Actually, the implementation would probably have a heart attack if you
> > asked for 100,000 pages so you may need to sit in a loop there;
> > we'll see).
> 
> If nr_pages is > than number of pages really freable will it return
> NULL or stall the calling process forever?

Good point.  In current Linus tree, it could be oom-killed.  Later,
lack of __GFP_FS will prevent that.  But it could loop forever.
I guess you'll need to drop the __GFP_WAIT and yield yourself, let
kswapd free the next batch of pages.

We need to do something more robust than this.  I'll cook something up.