Re: [rfc][patch] DriverFS Topology + per-node (NUMA) meminfo

Rusty Russell (rusty@rustcorp.com.au)
Tue, 29 Oct 2002 14:09:47 +1100


In message <3DBDDF70.9050609@us.ibm.com> you write:
> 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.

I think you really want them there all the time. Otherwise it's hard
to use the entried to bring them online 8)

It's easy: just don't entry i if "cpu_possible(i)" is false.

> 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

Cool, I missed that. As long as they're somewhere, I'm happy.

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

OK, I'll come to the mountain then. 8)

Rusty.

--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
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/