[lkml]   [2006]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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);
> } else if (x < -STAT_THRESHOLD) {
> zone_page_state_add(x - STAT_THRESHOLD/2, zone, item);
> }
> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-06-29 20:25    [W:0.105 / U:0.748 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site