lkml.org 
[lkml]   [2007]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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






\
 
 \ /
  Last update: 2007-12-14 14:59    [W:0.089 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site