From: Niels C. <nc...@us...> - 2001-12-02 07:17:42
|
Hi Paul Dorwin, When you come back from vacation, I have just started taking the rest of the year off. Although I have a couple of home improvement projects laid out for me, I probably will check-in now and then. I think I understand what you were originally "tasked with", and maybe this is not exactly the best place to continue the discussion about a generic topology and instrumentation design. Where should we take it? A couple of comments to your last response: > This is not intended to be a controlling subsystem. Heck, why not? Why not use the topology and access mechanism to control? Adding the ability to control simply means adding methods to attributes. > I don't believe this belongs in devfs as I am not writing device > drivers for cpus and memory. I am simply providing static infomration. > > I don't believe this belongs in procfs either. Applications that care > about topology data are going to be running on large systems. > Processing /proc would be too expensive. A simple program written > in C can spit out the same thing that you would find in a /proc > interface. I'm guilty for not having studied other aspects of devfs than what I need to make a device driver that uses it, but I agree with your comments about procfs. On the other hand, since /proc is loved by so many, what does it matter if somebody adds the C code to spit the topology to /proc? > Having said that, if it turns out that this can be used or extended > for other purposes, then that would be a major bonus. Yes, yes, but to make it suitable for those other purposes, we must construct this so that what you show in your diagram is a special case and not the only case. > http://lse.sourceforge.net/numa/topology/topo_diagram.html > In other words, > by looking at the system container, you know that there are two nodes > in the system. I think it should be: You can see that there are two somethings in the system. By looking at the type of those somethings you find that they are two CPU nodes. As you look again, you find some otherthings, which turn out to be power supplies or fuel tanks, or whatever. Agree? > Now, suppose you wanted information about cpu0 and you didn't want to > walk the graph? Simple, contruct an objid and grab the pointer: > topo_obj_get(TOPO_OBJID(TOPO_TYPE_CPU, 0); That kind of access is, in my opinion, access by field or attribute as in wildcarding or an SQL query. The ID should not be constructed from type fields but be an opaque type (which may be implemented as a physical pointer in kernel space, but that is really not important). I suspect that, in kernel space, most users such as the scheduler would already know the object IDs, having traversed the topology at boot, and/or would use the topology structures as an integral part of what they need to interrogate before deciding on which processor to use or whatever. > Finally, just to show that this is not Numa specific, this could > easily be applied to a standard SMP system. In this case, > the Node 0 Container would become the only container in the > system. The system container would then contain the object ids > of the 4 cpus and single memory block. This is shown in figure 3 of > the diagrams. I would prefer to see the good old SMP just like I see the NUMA box, except that the system container has only one node container to point to (and a fuel tank, of course). > How about if I refer to the > use of object ids in this manner as a logical pointer? Logical pointer is a good term. Anything I ever said about pointers in this discussion should be taken to mean logical pointers -- except for when I say address pointer or physical pointer as I did above. Now go and enjoy your vacation. Niels |
From: Niels C. <nc...@us...> - 2001-12-02 07:53:33
|
Oh my, I thought I was the only one sitting up at night waiting for a life to come my way ... ! I have a few comnents to your last one, Paul, and then I'll get on with my port to IA64: | > I don't believe this belongs in devfs as I am not writing device | > drivers for cpus and memory. I am simply providing static infomration. | | Yes, I tend to agree. Well, maybe not static after all with hot-pluggable everythings. You (Paul J) already addressed this in one of your first emails by suggesting some sort of alerter. We will also see extended use of partitioning (oh, my, another one we did not address; do we have one topology for the physical box and one for each of the smaller logical partitions or what? See how attributes in the arc can be useful?). Anyway, "static" is probably not the best way to describe it. | > objects are by object ID, not the pointer. How about if I refer | > to the use of object ids in this manner as a logical pointer? | | Probably "object id" is better, if only because "logical pointer" | sounds quite nebulous. Although I answered Paul Dorwin that I found logical pointer to be a good term, I personally prefer ID (whether you prepend "object" or not) or "key". However, when Paul put it like this: "the use of object ids in this manner" I got sidetracked. Let's stick to "access by (object) ID". I'll go and lookup "nebulous". Niels |
From: Paul J. <pj...@sg...> - 2001-12-02 08:37:00
|
On Sun, 2 Dec 2001, Niels Christiansen wrote: > ... We will also see extended use of partitioning (oh, my, > another one we did not address; do we have one topology for > the physical box and one for each of the smaller logical > partitions or what? I'd imagine that it is one topology per system image. I won't rest till it's the best ... Manager, Linux Scalability Paul Jackson <pj...@sg...> 1.650.933.1373 |
From: Niels C. <nc...@us...> - 2001-12-02 08:56:32
|
| > ... We will also see extended use of partitioning (oh, my, | > another one we did not address; do we have one topology for | > the physical box and one for each of the smaller logical | > partitions or what? | | I'd imagine that it is one topology per system image. Yes, we need one topology per "logical system" or "system image" but the "hyper" needs another view, doesn't she? What if you are the person/application controlling the partitioning? What if you want to adjust the partitioning dynamically as your load fluctuates over the day? Even if you don't provide a "hyper" topology, you are hardly static if somebody can change the partitioning at any time and thus change your system image. Niels |
From: Paul J. <pj...@sg...> - 2001-12-02 09:05:54
|
On Sun, 2 Dec 2001, Niels Christiansen wrote: > Yes, we need one topology per "logical system" or "system image" > but the "hyper" needs another view, doesn't she? What if you > are the person/application controlling the partitioning? What > if you want to adjust the partitioning dynamically as your load > fluctuates over the day? To a first approximation, that could just be like hot plugging additional equipment into the partition? |
From: Paul J. <pj...@sg...> - 2001-12-02 08:30:05
|
On Sun, 2 Dec 2001, Niels Christiansen wrote: > Hi Paul Dorwin, > > > This is not intended to be a controlling subsystem. > > Heck, why not? Why not use the topology and access mechanism to > control? Adding the ability to control simply means adding > methods to attributes. If one is within a single runtime that supports methods and attributes, such as the runtime of an object oriented language, or making do with more simple means, within the runtime of the linux kernel, say, then yes it is just adding methods. But if one is crossing at least the user/kernel boundary, and perhaps multiple language and process boundaries, then adding controlling methods is no longer a simple means. Have a good vacation, Paul. I won't rest till it's the best ... Manager, Linux Scalability Paul Jackson <pj...@sg...> 1.650.933.1373 |