Re: [PATCH] fix free swap cache latency

[Nick Piggin <nickpiggin@yahoo.com.au>]

Andrew Morton wrote:
> Hugh Dickins <hugh@veritas.com> wrote:
> 
>> 			(*zap_work)--;
>> 			continue;
>> 		}
>>+
>>+		(*zap_work) -= PAGE_SIZE;
> 
> 
> Sometimes we subtract 1 from zap_work, sometimes PAGE_SIZE.  It's in units
> of bytes, so PAGE_SIZE is correct.  Although it would make sense to
> redefine it to be in units of PAGE_SIZE.  What's up with that?
> 

Subtracting 1 if there is no work to do for that cacheline entry.

> Even better, define it in units of "approximate number of touched
> cachelines".  After all, it is a sort-of-time-based thing.
> 

Yeah that was the rough intention, but I never actually measured
to see whether the results were right.

The pte_none case touches about 1/32 of a cacheline on my P4
(add a bit for setup costs, subtract a bit for linear prefetchable
access over multiple lines).

pte_present touches the pte, the page once or twice -- first
directly, then from mmu gather, the vma and the mapping (mostly be
the same though so cost is small), a whole host of locks and atomic
operations (put_page_testzero, lru_lock, tree_lock, page_remove_rmap,
zone->lock), an IPI to other CPUs, tlb invalidates etc. some things
batched, some not.

So it gets hard to count, especially if you have other CPUs contending
the same locks. I suspect the per-page cost is not really 128 cache
misses most of the time, but it was just a number I pulled out. Anyone
can feel free to turn the knob if they feel they have a better idea.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com