![]() | |||||||||||
Messages in this thread |
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/ | ||||||||||
| Last update: 2005-03-22 14:06 [from the cache] ©2003-2008 | |||||||||||