Messages in this thread | | | Date | Sat, 14 Sep 2002 06:57:46 -0700 | From | Andrew Morton <> | Subject | Re: Good way to free as much memory as possible under 2.5.34? |
| |
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/
| |