Re: [CFT][RFC] HT scheduler

[Nick Piggin]

Andrew Theurer wrote:

> > In message <3FD7F1B9.5080100@xxxxxxxxxxxxxxx> you write:
> >
> > > http://www.kerneltrap.org/~npiggin/w26/
> > > Against 2.6.0-test11
> > >
> > > This includes the SMT description for P4. Initial results shows
> > > comparable performance to Ingo's shared runqueue's patch on a dual P4
> > > Xeon.
> > I'm still not convinced.  Sharing runqueues is simple, and in fact
> > exactly what you want for HT: you want to balance *runqueues*, not
> > CPUs.  In fact, it can be done without a CONFIG_SCHED_SMT addition.
> >
> > Your patch is more general, more complex, but doesn't actually seem to
> > buy anything.  It puts a general domain structure inside the
> > scheduler, without putting it anywhere else which wants it (eg. slab
> > cache balancing).  My opinion is either (1) produce a general NUMA
> > topology which can then be used by the scheduler, or (2) do the
> > minimal change in the scheduler which makes HT work well.
>
> FWIW, here is a patch I was working on a while back, to have multilevel NUMA 
> heirarchies (based on arch specific NUMA topology) and more importantly, a 
> runqueue centric point of view for all the load balance routines.  This patch 
> is quite rough, and I have not looked at this patch in a while, but maybe it 
> could help someone?
>
> Also, with runqueue centric approach, shared runqueues should just "work", so 
> adding that to this patch should be fairly clean.  
>
> One more thing, we are missing some stuff in the NUMA topology, which Rusty 
> mentions in another email, like core arrangement, arch states, cache 
> locations/types -all that stuff eventually should make it into some sort of 
> topology, be it NUMA topology stuff or a more generic thing like sysfs.  
> Right now we are a bit limited at what the scheduler looks at, just 
> cpu_to_node type stuff...

Hi Andrew,
sched domains can do all this. It is currently set up using just the
simple NUMA toplogy, so its much the same, but the potential is there.

It implements a structure to describe topology in detail which is
used to drive scheduling choices. It could quite easily be extended
to include more memory information and become a general description
for topology.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/