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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:36 EST