Re: [PATCH] shrinker support for the mmu cache

[Avi Kivity <avi@qumranet.com>]

Marcelo Tosatti wrote:
> On Mon, Mar 17, 2008 at 04:41:18PM +0200, Avi Kivity wrote:
>   
>> Marcelo Tosatti wrote:
>>     
>>>> While aging is not too hard to do, I don't think it would add much in 
>>>> practice; we rarely observe mmu shadow pages being recycled due to 
>>>> memory pressure.  So this is mostly helpful for preventing a VM from 
>>>> pinning memory when under severe memory pressure, where we don't expect 
>>>> good performance anyway.
>>>>    
>>>>         
>>> Issue is that the shrinker callback will not be called only under
>>> severe memory pressure, but for normal system pressure too.
>>>
>>>  
>>>       
>> How much shrinkage goes on under normal pressure?
>>     
>
> It depends on the number of LRU pages scanned and the size of the cache.
>
> Roughly the number of LRU pages scanned divided by shrinker->seeks,
> relative to cache size (mm/vmscan.c shrink_slab).
>
>   

Since the maximum cache size is a small fraction of memory size, I think 
we should be okay here.

>> Rebuilding a single shadow page costs a maximum of 512 faults (so about 
>> 1 msec).  If the shrinker evicts one entry per second, this is a 
>> performance hiy of 0.1%.
>>
>> Perhaps if we set the cost high enough, the normal eviction rate will be 
>> low enough.
>>     
>
> I think its pretty easy to check for the referenced bit on pages to
> avoid recently used ones from being zapped.
>   

Not so easy:

- the pages don't have an accessed bit, the parent ptes do, so we need 
to scan the parent ptes list
- pages start out referenced, so we need to age them in two stages: 
first clear the accessed bits (and move them back to the tail of the 
queue); if we find a page on the head with all accessed bits clear, we 
can throw it away.
- root pages don't have parent ptes, so we need to track access to them 
manually
- if the accessed bit clearing rate is too high, it loses its meaning

Nothing horribly hard, but not trivial either.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/