Messages in this thread | | | Date | Thu, 20 Apr 2006 18:25:53 -0700 | From | Andrew Morton <> | Subject | Re: [patch] smpnice: don't consider sched groups which are lightly loaded for balancing |
| |
Peter Williams <pwil3058@bigpond.net.au> wrote: > > Andrew Morton wrote: > > "Siddha, Suresh B" <suresh.b.siddha@intel.com> wrote: > >> updated patch appended. thanks. > > > > Where are we up to with smpnice now? Are there still any known > > regressions/problems/bugs/etc? > > One more change to move_tasks() is required to address an issue raised > by Suresh w.r.t. the possibility unnecessary movement of the highest > priority task from the busiest queue (possible because of the > active/expired array mechanism). I hope to forward a patch for this > later today.
OK.
> After that the only thing I would like to do at this stage is modify > try_to_wake_up() so that it tries harder to distribute high priority > tasks across the CPUs. I wouldn't classify this as absolutely necessary > as it's really just a measure that attempts to reduce latency for high > priority tasks as it should get them onto a CPU more quickly than just > sticking them anywhere and waiting for load balancing to kick in if > they've been put on a CPU with a higher priority task already running. > Also it's only really necessary when there a lot of high priority tasks > running. So this isn't urgent and probably needs to be coordinated with > Ingo's RT load balancing stuff anyway.
Sure, we can leave things like that until later.
> > Has sufficient testing been done for us to > > know this?
I should have said "testing for regressions". We know that smpnice improves some things. My concern is that it doesn't cause any non-silly workloads to worsen. Once we're at that stage I think we're ready to go.
IOW: at this stage we should concentrate upon not taking any workloads backwards, rather than upon taking even more workloads even more forwards. That can come later.
> I run smpnice kernels on all of my SMP machines all of the time. But I > don't have anything with more than 2 CPUs so I've been relying on their > presence in -mm to get wider testing on larger machines.
Sure. A mortal doesn't have the hardware and isn't set up to test certain high-value workloads...
> As load balancing is inherently probabilistic I don't think that we > should hold out for "perfect".
Sure. "same or better" is the aim here. - 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/
| |