Re: [PATCH 1/2] Have kswapd keep a minimum order free other than order-0

[Mel Gorman <mel@csn.ul.ie>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; CHARSET=X-UNKNOWN; FORMAT=flowed, Size: 1660 bytes --]

On Wed, 16 May 2007, Nick Piggin wrote:

> Mel Gorman wrote:
>> On Tue, 15 May 2007, Nicolas Mailhot wrote:
>> 
>>> Le lundi 14 mai 2007 à 19:24 +0100, Mel Gorman a écrit :
>>> 
>>>> On (14/05/07 11:13), Christoph Lameter didst pronounce:
>>>> 
>>>>> I think the slub fragment may have to be this way? This calls
>>>>> raise_kswapd_order on each kmem_cache_create with the order of the cache
>>>>> that was created thus insuring that the min_order is correctly.
>>>>> 
>>>>> Signed-off-by: Christoph Lameter <clameter@sgi.com>
>>>>> 
>>>> 
>>>> Good plan. Revised patch as follows;
>>> 
>>> 
>>> Kernel with this patch and the other one survives testing. I'll stop
>>> heavy testing now and consider the issue closed.
>>> 
>> 
>> That is good news, thanks for the report.
>> 
>>> Thanks for looking at my bug report.
>>> 
>> 
>> Thank you very much for your testing. I know it was a lot to ask to tie a 
>> machine up for a few days.
>
> Hmm, so we require higher order pages be kept free even if nothing is
> using them? That's not very nice :(
>

Not quite. We are already required to keep a minimum number of pages free 
even though nothing is using them. The difference is that if it is known 
high-order allocations are frequently required, the freed pages will be 
contiguous. If no one calls raise_kswapd_order(), kswapd will continue 
reclaiming at order-0. Arguably, e1000 should also be calling 
raise_kswapd_order() when it is using jumbo frames.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab