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 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/