Re: [CFT][RFC] HT scheduler

[Nick Piggin]

bill davidsen wrote:

> In article <3FDAB517.4000309@xxxxxxxxxxxxxxx>,
> Nick Piggin  <piggin@xxxxxxxxxxxxxxx> wrote:
>
> | Possibly. But it restricts your load balancing to a specific case, it
> | eliminates any possibility of CPU affinity: 4 running threads on 1 HT
> | CPU for example, they'll ping pong from one cpu to the other happily.
>
> Huh? I hope you meant sibling and not CPU, here.

It was late when I wrote that! You are right, of course.

> | I could get domains to do the same thing, but at the moment a CPU only looks
> | at its sibling's runqueue if they are unbalanced or is about to become idle.
> | I'm pretty sure domains can do anything shared runqueues can. I don't know
> | if you're disputing this or not?
>
> Shared runqueues sound like a simplification to describe execution units
> which have shared resourses and null cost of changing units. You can do
> that by having a domain which behaved like that, but a shared runqueue
> sounds better because it would eliminate the cost of even considering
> moving a process from one sibling to another.

You are correct, however it would be a miniscule cost advantage,
possibly outweighed by the shared lock, and overhead of more
changing of CPUs (I'm sure there would be some cost).

> Sorry if I'm mixing features of Con/Nick/Ingo approaches here, I just
> spent some time looking at the code for several approaches, thinking
> about moving jobs from the end of the runqueue vs. the head, in terms of
> fair vs. overall cache impact.
>
> | >But this is my point.  Scheduling is one part of the problem.  I want
> | >to be able to have the arch-specific code feed in a description of
> | >memory and cpu distances, bandwidths and whatever, and have the
> | >scheduler, slab allocator, per-cpu data allocation, page cache, page
> | >migrator and anything else which cares adjust itself based on that.
>
> And would shared runqueues not fit into that model?

Shared runqueues could be built from that model

> | (Plus two threads / siblings per CPU, right?)
> | 
> | I agree with you here. You know, we could rename struct sched_domain, add
> | a few fields to it and it becomes what you want. Its a _heirachical set_
> | of _sets of cpus sharing a certian property_ (underlining to aid grouping.
> | 
> | Uniform access to certian memory ranges could easily be one of these
> | properties. There is already some info about the amount of cache shared,
> | that also could be expanded on.
> | 
> | (Perhaps some exotic architecture  would like scheduling and memory a bit
> | more decoupled, but designing for *that* before hitting it would be over
> | engineering).
> | 
> | I'm not going to that because 2.6 doesn't need a generalised topology
> | because nothing makes use of it. Perhaps if something really good came up
> | in 2.7, there would be a case for backporting it. 2.6 does need improvements
> | to the scheduler though.
>
> | But if sched domains are accepted, there is no need for shared runqueues,
> | because as I said they can do anything sched domains can, so the code would
> | just be a redundant specialisation - unless you specifically wanted to share
> | locks & data with siblings.
>
> I doubt the gain would be worth the complexity, but what do I know?

Sorry I didn't follow, gain and complexity of what?

Earlier in the thread Ingo thought my approach is simpler. code size is the
same size, object size for my patch is significantly smaller, and it does
more. Benchmarks have so far shown that my patch is as performant as shared
runqueues.


-
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/