Re: [PATCH] fix free swap cache latency

[Hugh Dickins <hugh@veritas.com>]

On Fri, 17 Mar 2006, Nick Piggin wrote:
> 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.
> .... 
> 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.

Accounting PAGE_SIZE for a present pte or swap entry preserves the
same latency allowance as Ingo made when he introduced ZAP_BLOCK_SIZE,
so it assures us of no regression on those.

I've always felt a pte_none entry probably ought to count for more than
1 on that scale, perhaps 16.  But likewise never did any calculation or
research, nor heard of any complaints - and large stretches of pte_none
should be quite a common case, after your copy_page_range optimization.

Plus we've both regarded that code as just for the interim, while both
of us (I see today) pursue preemptible mmu_gather solutions (I'll look
at your patch and report, but not today).

Hugh