Messages in this thread | | | Date | Fri, 14 Dec 2007 08:57:20 -0500 | From | Mark Lord <> | Subject | Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ? |
| |
Mel Gorman wrote: > On (13/12/07 16:37), Andrew Morton didst pronounce: >> On Thu, 13 Dec 2007 19:30:00 -0500 >> Mark Lord <liml@rtr.ca> wrote: >> >>> Here's the commit that causes the regression: >>> >>> ... >>> >>> --- a/mm/page_alloc.c >>> +++ b/mm/page_alloc.c >>> @@ -760,7 +760,8 @@ static int rmqueue_bulk(struct zone *zone, unsigned int order, >>> struct page *page = __rmqueue(zone, order, migratetype); >>> if (unlikely(page == NULL)) >>> break; >>> - list_add_tail(&page->lru, list); >>> + list_add(&page->lru, list); >> well that looks fishy. >> > > The reasoning behind the change was the first page encountered on the list > by the caller would have a matching migratetype. I failed to take into > account the physical ordering of pages returned. I'm setting up to run some > performance benchmarks of the candidate fix merged into the -mm tree to see > if the search shows up or not. I'm testing against 2.6.25-rc5 but it'll > take a few hours to complete. ..
Thanks, Mel. This is all with CONFIG_SLAB=y, by the way.
Note that it did appear to behave better with CONFIG_SLUB=y when I accidently used that .config on my 4GB machine here. Physical segments of 4-10 pages happended much more common than with CONFIG_SLAB=y on my 3GB machine Slightly "apples and oranges" there, I know, but at least both were x86-32. :)
So I would expect CONFIG_SLAB to be well off with this patch under most (all?) conditions, but dunno about CONFIG_SLUB.
Cheers
| |