Re: [Lse-tech] [RFC PATCH] scheduler: Dynamic sched_domains

[Erich Focht]

On Friday 08 October 2004 12:40, Nick Piggin wrote:
> Erich Focht wrote:
> > Could you please describe the API you had in mind for that?
> > 
> 
> First of all, I think it may be easiest to allow the user to specify
> which cpus belong to which exclusive domains, and have them otherwise
> built in the shape of the underlying topology. So for example if your
> domains look like this (excuse the crappy ascii art):
> 
> 0 1  2 3  4 5  6 7
> ---  ---  ---  ---  <- domain 0
>   |    |    |    |
>   ------    ------   <- domain 1
>      |        |
>      ----------      <- domain 2 (global)
> 
> And so you want to make a partition with CPUs {0,1,2,4,5}, and {3,6,7}
> for some crazy reason, the new domains would look like this:
> 
> 0 1  2  4 5    3  6 7
> ---  -  ---    -  ---  <- 0
>   |   |   |     |   |
>   -----   -     -   -   <- 1
>     |     |     |   |
>     -------     -----   <- 2 (global, partitioned)
> 
> Agreed? You don't need to get fancier than that, do you?
> 
> Then how to input the partitions... you could have a sysfs entry that
> takes the complete partition info in the form:
> 
> 0,1,2,3 4,5,6 7,8 ...
> 
> Pretty dumb and simple.

Hmmm, this is unusable as long as you don't tell me how to create new
levels and link them together. Adding CPUs is the simplest
part. I'm with Matt here, the filesystem approach is the most
elegant. On the other hand something simple for the start wouldn't be
bad. It would show immediately whether Matt's or your way of dealing
with domains is better suited for relinking and reorganising the
domains structure dynamically. Functionality could be something like:
- list domains
- create domain
- add child domains
- link in parent domain
We're building this from bottom (cpus) up and need to take care of the
unlinking of the global domain when inserting something. But otherwise
this could be sufficient.

Regards,
Erich

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