Messages in this thread | | | Date | Fri, 17 Mar 2006 13:52:26 +1100 | From | Nick Piggin <> | Subject | Re: [PATCH] fix free swap cache latency |
| |
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/
| |