Messages in this thread | | | Date | Sun, 09 Nov 2003 07:34:51 -0800 | From | "Martin J. Bligh" <> | Subject | Re: [PATCH] Fix find busiest queue 2.6.0-test9 |
| |
>> prev_cpu_load[i] is nr_running of cpu i last time this operation was >> performed. Either it, or the current nr_running is taken, whichever >> is lower. >> >> I guess its done this way for cache benefits, but it was correct as >> Ingo intended. For example, with Con's patch you can see >> rq_src->prev_cpu_load[i] will only ever use the ith position in the array. > > Yes. The prev_cpu_load[] array takes a snapshot of the run queue lengths > seen by the current rq (this_rq). The code is ok as is, and the reason is > to avoid stealing tasks too fast from remote CPU (cache thing). Time ago I > also tried to store an K-average (by varying K) rq length in > prev_cpu_load[] instead of a simple min-of-two-values: > > this_rq->prev_cpu_load[i] = (K * this_rq->prev_cpu_load[i] + rq_src->nr_running) / (K + 1); > > I couldn't see any major improvements in my 2SMP (never tried on bigger SMP/NUMA).
I ran it on the 16-way - no difference in performance. If the code is correct as was before (and I agree, it seems it was), perhaps it's just in need of a big fat comment to explain the confusion? ;-)
M.
- 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/
| |