Re: ZVC: Increase threshold for larger processor configurationss

[Andrew Morton <akpm@osdl.org>]

On Thu, 29 Jun 2006 11:22:45 -0700 (PDT)
Christoph Lameter <clameter@sgi.com> wrote:

> On Wed, 28 Jun 2006, Andrew Morton wrote:
> 
> > An alternative would be to calculate stat_threshold at runtime, based on
> > the cpu_possible count (I guess).  Or even:
> > 
> > static inline int stat_threshold(void)
> > {
> > #if NR_CPUS <= 32
> > 	return 32;
> > #else
> > 	return dynamically_calculated_stat_threshold;
> > #endif
> > }
> 
> Thats one more memory reference. Hmmm... We could place the threshold in 
> the same cacheline. That would also open up the possbiliity of dynamically 
> calculating the threshold.

yup.

> > Did you consider my earlier suggestion about these counters?  That, over the
> > short-term, they tend to count in only one direction?  So we can do
> > 
> > 	if (x > STAT_THRESHOLD) {
> > 		zone_page_state_add(x + STAT_THRESHOLD/2, zone, item);
> > 		x = -STAT_THRESHOLD/2;
> > 	} else if (x < -STAT_THRESHOLD) {
> > 		zone_page_state_add(x - STAT_THRESHOLD/2, zone, item);
> > 		x = STAT_THRESHOLD;
> > 	}
> > 
> > that'll give an decrease in contention while not consuming any extra
> > storage and while (I think) increasing accuracy.
> 
> Uhh... We are overcompensating right? Pretty funky idea that is new to me 
> and that would require some thought.

See inbox ;)

> This would basically increase the stepping by 50% if we are only going in 
> one direction.

yes.

> If we are doing a mixture of allocations and deallocations (or pages being 
> marked dirty / undirty, mapping unmapping) then this may potentially
> increase the number of updates and therefore the cacheline contentions.

Yes.  I'd handwavingly contend that this is a rare situation.

A lot of the counters only ever count in one direction!  So we could even
skew them by an entire STAT_THRESHOLD.