[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);
    > x = -STAT_THRESHOLD/2;
    > } 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.020 / U:23.220 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site