Messages in this thread | | | Date | Sat, 8 Nov 2003 16:44:52 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [PATCH] Fix find busiest queue 2.6.0-test9 |
| |
On Sun, 9 Nov 2003, Nick Piggin wrote:
> Andrew Morton wrote: > > >Con Kolivas <kernel@kolivas.org> wrote: > > > >>Hi > >> > >>I believe this is a simple typo / variable name mixup between rq_src and > >>this_rq. So far all testing shows positive (if minor) improvements. > >> > >> > > > >Looks right to me. I'll queue this up for the 2.6.1 deluge. > > > > 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).
- Davide
- 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/
| |