Re: ZVC: Increase threshold for larger processor configurationss

[Christoph Lameter <clameter@sgi.com>]

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.

> 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.

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

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.
-
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/