public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: colpatch@us.ibm.com
Cc: mochel@osdl.org, alan@lxorguk.ukuu.org.uk, davej@suse.de,
	mjbligh@us.ibm.com, akpm@zip.com.au,
	linux-kernel@vger.kernel.org
Subject: Re: [rfc][patch] DriverFS Topology + per-node (NUMA) meminfo
Date: Tue, 29 Oct 2002 10:24:52 +1100	[thread overview]
Message-ID: <20021028233518.53C5E2C105@lists.samba.org> (raw)
In-Reply-To: Your message of "Mon, 28 Oct 2002 10:58:50 -0800." <3DBD88EA.7000402@us.ibm.com>

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:
> > 
> > 
> >>[ patch ]
> > 
> > 
> > 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)

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

> But it also 
> offers node-topology info and per-node meminfo.  I'd like to see them 
> work together.  Most of the conflict is simply in where we put the 
> driverfs CPU code.  Your patch moves it (w/ additions) to kernel/cpu.c, 
> whereas mine moves it (also w/ different additions) to 
> drivers/base/cpu.c.  I think that the drivers/base is a bit more 
> appropriate for the driverfs specific code (struct device_driver 
> cpu_driver, the array of cpu_devices...).  Also, I made the registration 
> routines arch-specific, because I figured that different architectures 
> may want to add arch-specific info, and register devices at different 
> times, in different orders, etc.  I also didn't incorporate the 
> cpu_notifier stuff, which I should have.
> 
> 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.

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

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

But Patrick is the architect, I'm just a grunt, so it's his call 8)
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

  reply	other threads:[~2002-10-28 23:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-21 21:37 [rfc][patch] DriverFS Topology + per-node (NUMA) meminfo Matthew Dobson
2002-10-21 21:48 ` Patrick Mochel
2002-10-21 21:50   ` Matthew Dobson
2002-10-28  3:05     ` Rusty Russell
2002-10-28 18:58       ` Matthew Dobson
2002-10-28 23:24         ` Rusty Russell [this message]
2002-10-29  1:08           ` Matthew Dobson
2002-10-29  3:09             ` Rusty Russell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021028233518.53C5E2C105@lists.samba.org \
    --to=rusty@rustcorp.com.au \
    --cc=akpm@zip.com.au \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=colpatch@us.ibm.com \
    --cc=davej@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjbligh@us.ibm.com \
    --cc=mochel@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox