Messages in this thread | | | Date | Thu, 29 Jun 2006 11:22:45 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: ZVC: Increase threshold for larger processor configurationss |
| |
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/
| |