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?
If it will return NULL I'm happy to use that... Otherwise its not too
usable because I do not want to OOM the machine.
Pavel
-- Casualities in World Trade Center: ~3k dead inside the building, cryptography in U.S.A. and free speech in Czech Republic. - 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