lkml.org 
[lkml]   [2002]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [rfc][patch] DriverFS Topology + per-node (NUMA) meminfo
Rusty Russell wrote:
> In message <3DBD88EA.7000402@us.ibm.com> you write:
>
>>Rusty Russell wrote:
>>
>>>On Mon, 21 Oct 2002 14:50:25 -0700
>>>Matthew Dobson <colpatch@us.ibm.com> wrote:
>>>
>>>This clashes with my "move cpu driverfs to generic code" patch.
>>
>>Yes, yes it does. It does a lot of similar things though.
>
> Hey, great minds think alike 8)

Indeed!


>>My patch does not take advantage of the DECLARE_PER_CPU macros, etc.
>
> A minor optimization which can be done later. The important bit is
> not creating entries for cpus where !cpu_possible(cpu).

Very true. I only instantiate entries for cpus that are online at the
time of the initcall. With the cpu callback stuff that you had in your
patch, we can easily instantiate cpus that (magically? ;) come on line
at a later point.


>> <snip>
>>
>>What do you think of my patch (other than the obvious that it conflicts
>>with yours)?
>
> If I'm reading correctly, you move the cpus under "node" dirs when
> it's a NUMA system. I can see the cute appeal, but it makes it harder
> to answer "how many cpus do I have?": a program would need to do a
> "find" which is kinda icky (also hard to write HOWTOs). So I'd prefer
> symlinks to the node, and no hierarchy.

Well, in either (NUMA/non-NUMA) case, there are symlinks to the CPUs
under class/cpu/devices:
[root@elm3b79 devices]# ls -al class/cpu/devices/
total 0
drwxr-xr-x 2 root root 0 Oct 25 07:59 .
drwxr-xr-x 4 root root 0 Oct 25 07:59 ..
lrwxrwxrwx 1 root root 22 Oct 25 07:59 0 ->
../../../root/sys/cpu0
lrwxrwxrwx 1 root root 22 Oct 25 07:59 1 ->
../../../root/sys/cpu1
lrwxrwxrwx 1 root root 22 Oct 25 07:59 2 ->
../../../root/sys/cpu2
lrwxrwxrwx 1 root root 22 Oct 25 07:59 3 ->
../../../root/sys/cpu3
lrwxrwxrwx 1 root root 22 Oct 25 07:59 4 ->
../../../root/sys/cpu4
lrwxrwxrwx 1 root root 22 Oct 25 07:59 5 ->
../../../root/sys/cpu5
lrwxrwxrwx 1 root root 22 Oct 25 07:59 6 ->
../../../root/sys/cpu6
lrwxrwxrwx 1 root root 22 Oct 25 07:59 7 ->
../../../root/sys/cpu7

These actually work really well because they don't move.. I like the
idea (maybe it is just cute) of exposing the topology in a hierarchical
(directory) fashion when possible. And class/cpu/devices seems like a
fairly logical place to go inquiring about cpus...


> driver/base/cpu.c should probably be moved into kernel/cpu.c anyway.

What about driver/base/node.c & memblk.c? My thoughts were to maintain
a separation between driverfs-only and other in-core code.


> I think exposing the struct cpu array is a good idea, so archs can add
> properties if they want (ie. node information).

Cool. I didn't think it was particularly important at first, but Pat
showed me the error of my ways ;)


> But Patrick is the architect, I'm just a grunt, so it's his call 8)
> Rusty.

Good call! What do you think, O architect? ;)

Cheers!

-Matt

-
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 13:30    [W:0.249 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site