Messages in this thread | | | From | Erich Focht <> | Subject | Re: [Lse-tech] [RFC PATCH] scheduler: Dynamic sched_domains | Date | Sun, 10 Oct 2004 14:45:58 +0200 |
| |
On Saturday 09 October 2004 03:05, Matthew Dobson wrote: > On Fri, 2004-10-08 at 15:51, Erich Focht wrote: > > 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. > > I personally like to think of it from the top down. The internal API I > came up with looks like: > > create_domain(parent_domain, type); > destroy_domain(domain); > add_cpu_to_domain(cpu, domain); > > So you basically build your domain from the top down, from your 1 or > more top-level domains, down to your lowest level domains. You then add > cpus (1 or more per domain) to the leaf domains in the tree you built. > Those cpus cascade up the tree, and the whole tree knows exactly which > cpus are contained in each domain in it. > > I think these are the three main functions you need to construct pretty > much any conceivable, useful sched_domains hierarchy.
I'd suggest adding: reparent_domain(domain, new_parent_domain);
When I said that the domains tree is standing on its leaves I meant that the core components are the CPUs. Or the Nodes, if you already have them. Or some supernodes, if you already have them. In a "normal" filesystem you have the root directory, create subdirectories and create files in them. Here you already have the files but not the structure (or the simplest possible structure).
Anyhow, the 4 command API can well be the guts of the directory operations API which I proposed.
Regards, Erich
- 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/
| |