Messages in this thread | | | From | kamezawa.hiroyu@jp ... | Date | Fri, 3 Oct 2008 00:25:44 +0900 (JST) | Subject | Re: Re: [PATCH 4/4] capture pages freed during direct reclaim for allocation by the reclaimer |
| |
----- Original Message -----
>On Thu, Oct 02, 2008 at 04:24:14PM +0900, KAMEZAWA Hiroyuki wrote: >> On Wed, 1 Oct 2008 13:31:01 +0100 >> Andy Whitcroft <apw@shadowen.org> wrote: >> >> > When a process enters direct reclaim it will expend effort identifying >> > and releasing pages in the hope of obtaining a page. However as these >> > pages are released asynchronously there is every possibility that the >> > pages will have been consumed by other allocators before the reclaimer >> > gets a look in. This is particularly problematic where the reclaimer is >> > attempting to allocate a higher order page. It is highly likely that >> > a parallel allocation will consume lower order constituent pages as we >> > release them preventing them coelescing into the higher order page the >> > reclaimer desires. >> > >> > This patch set attempts to address this for allocations above >> > ALLOC_COSTLY_ORDER by temporarily collecting the pages we are releasing >> > onto a local free list. Instead of freeing them to the main buddy lists, >> > pages are collected and coelesced on this per direct reclaimer free list. >> > Pages which are freed by other processes are also considered, where they >> > coelesce with a page already under capture they will be moved to the >> > capture list. When pressure has been applied to a zone we then consult >> > the capture list and if there is an appropriatly sized page available >> > it is taken immediatly and the remainder returned to the free pool. >> > Capture is only enabled when the reclaimer's allocation order exceeds >> > ALLOC_COSTLY_ORDER as free pages below this order should naturally occur >> > in large numbers following regular reclaim. >> > >> > Thanks go to Mel Gorman for numerous discussions during the development >> > of this patch and for his repeated reviews. >> > >> >> Hmm.. is this routine better than >> mm/memory_hotplug.c::do_migrate_range(start_pfn, end_pfn) ? > >Are you suggesting that it might be more adventageous to try and migrate >things out of this area as part of reclaim? If so then I tend to agree, >though that would be a good idea generally with or without capture. > >/me adds it to his todo list to test that out. > I just remember I did the same kind of work to offline pages. Sorry for noise.
I just have an idea to support following kind of interface via memory hotplug This makes all pages in the section to be hugepage.
#echo huge > /sys/device/system/memory/memoryXXX/state (memory hotplug interface supports online/offline here.)
But no patches yet...
Thanks, -Kame
| |