From: "J.A. Magallón" <jamagallon@ono.com>
To: Ingo Oeser <ioe-lkml@rameria.de>
Cc: Ulrich Drepper <drepper@redhat.com>,
"Siddha, Suresh B" <suresh.b.siddha@intel.com>,
Andi Kleen <andi@firstfloor.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: getting processor numbers
Date: Wed, 4 Apr 2007 01:38:57 +0200 [thread overview]
Message-ID: <20070404013857.5495d055@werewolf-wl> (raw)
In-Reply-To: <200704032213.20244.ioe-lkml@rameria.de>
On Tue, 3 Apr 2007 22:13:07 +0200, Ingo Oeser <ioe-lkml@rameria.de> wrote:
> Hi Ulrich,
>
> On Tuesday 03 April 2007, Ulrich Drepper wrote:
> > So, anybody else has a proposal? This is a pressing issue and cannot
> > wait until someday in the distant future NUMA topology information is
> > easily and speedily accessible.
>
> Since for now you just need a fast and dirty hack, which will be replaced
> with better interfaces, I suggest creating a directory with some files in it.
> These should just contain, what you need to handle your most pressing cases.
>
> I propose /sys/devices/system/topology_counters/ for that.
> These can contain "online_cpu", "proped_cpu", "max_cpu"
> and maybe the same for nodes. All that as a simple file with an integer
> value.
>
> Since sysfs-attribute files are pollable (if the owners notifies sysfs
> on changes), you also have the notification system you need
> (select, poll, epoll etc.).
>
> If you promise to just keep the slow code around, than one day when the shiny
> NUMA topology stuff is ready, this directory can be completely removed and
> glibc (plus all their users) keeps working. It will then even work better with a
> new glibc version, which supports the shiny new NUMA topology stuff.
>
> The kernel can create these counters quiete easy, since most of them are
> the hamming weight (or population count) of some bitmaps.
>
> Does this sound like a proper hacky solution? :-)
>
Just a point of view from someone who has to parse /proc/cpuinfo.
That sort of file tree thing is useful to work from the command line but its
a kick in the a** to use from a program.
This makes you just to re-parse the tree each time you have to get the info
(open, read, atoi, close...) to fill your internal variables.
I don't know if its possible, but I would like something like:
__packt_it_tight_please struct cpumap_t {
u16 ncpus;
u16 ncpus_onln;
u16 ncpus_inmyset; // for procsets
// Here possibly more info about topology, pack-core-thread structure...
// in simple arrays...
};
struct cpumap_t *cpumap = mmap("/proc/sys/hw/cpumap",sizeof(struct cpumap_t));
for (...cpumap->ncpus_inmyset ....) //
As I said, I don't know if its possible. I vaguely remember some comments
against binary info in /proc...
Even it could be simplified if you realize some things:
- Usually people dont worry about if cpus are all the online ones or I'm
running in a proc set. Just want to know how many can I use.
- Don't care if they are hyper-threaded, cores os independent processors.
To adjust processing for hyper-threaded cpus, one needs to tie processes
to processors, and you need to be root for that.
Really, anything dependent on topology is not usable for normal programs,
because you need to be root to control that.
So topology is not so important.
Some (probably stupid) ideas...
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.1 (Cooker) for i586
Linux 2.6.20-jam08 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT
next prev parent reply other threads:[~2007-04-03 23:39 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-03 16:54 getting processor numbers Ulrich Drepper
2007-04-03 17:30 ` linux-os (Dick Johnson)
2007-04-03 17:37 ` Ulrich Drepper
2007-04-03 17:56 ` Dr. David Alan Gilbert
2007-04-03 18:11 ` Andi Kleen
2007-04-03 17:17 ` Ulrich Drepper
2007-04-03 17:22 ` Alan Cox
2007-04-03 17:30 ` Andi Kleen
2007-04-03 20:24 ` Jeremy Fitzhardinge
2007-04-03 17:27 ` Andi Kleen
2007-04-03 17:30 ` Ulrich Drepper
2007-04-03 17:35 ` Andi Kleen
2007-04-03 17:45 ` Ulrich Drepper
2007-04-03 17:58 ` Andi Kleen
2007-04-03 18:05 ` Ulrich Drepper
2007-04-03 18:11 ` Andi Kleen
2007-04-03 18:21 ` Ulrich Drepper
2007-04-03 17:44 ` Siddha, Suresh B
2007-04-03 17:59 ` Ulrich Drepper
2007-04-03 19:40 ` Jakub Jelinek
2007-04-03 20:13 ` Ingo Oeser
2007-04-03 23:38 ` J.A. Magallón [this message]
2007-04-03 19:55 ` Ulrich Drepper
2007-04-03 20:13 ` Siddha, Suresh B
2007-04-03 20:19 ` Ulrich Drepper
2007-04-03 20:32 ` Eric Dumazet
2007-04-03 20:20 ` Nathan Lynch
2007-04-03 19:15 ` Davide Libenzi
2007-04-03 19:32 ` Ulrich Drepper
2007-04-04 0:31 ` H. Peter Anvin
2007-04-04 0:35 ` Jeremy Fitzhardinge
2007-04-04 0:38 ` H. Peter Anvin
2007-04-04 5:09 ` Eric Dumazet
2007-04-04 5:16 ` H. Peter Anvin
2007-04-04 5:22 ` Jeremy Fitzhardinge
2007-04-04 5:40 ` H. Peter Anvin
2007-04-04 5:46 ` Eric Dumazet
2007-04-04 5:29 ` Eric Dumazet
2007-04-03 20:16 ` Andrew Morton
[not found] ` <4612BB89.8040102@redhat.com>
[not found] ` <20070403141348.9bcdb13e.akpm@linux-foundation.org>
2007-04-03 22:13 ` Ulrich Drepper
2007-04-03 22:48 ` Andrew Morton
2007-04-03 23:00 ` Ulrich Drepper
2007-04-03 23:23 ` Andrew Morton
2007-04-03 23:54 ` Ulrich Drepper
2007-04-04 2:55 ` Paul Jackson
2007-04-04 8:39 ` Oleg Nesterov
2007-04-04 9:39 ` Ingo Molnar
2007-04-04 8:57 ` Oleg Nesterov
2007-04-04 10:01 ` Ingo Molnar
2007-04-04 2:58 ` Paul Jackson
2007-04-04 3:04 ` Paul Jackson
2007-04-04 2:52 ` Paul Jackson
2007-04-04 2:04 ` Paul Jackson
2007-04-04 6:47 ` Jakub Jelinek
2007-04-04 7:02 ` Paul Jackson
2007-04-04 14:51 ` Cliff Wickman
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=20070404013857.5495d055@werewolf-wl \
--to=jamagallon@ono.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=drepper@redhat.com \
--cc=ioe-lkml@rameria.de \
--cc=linux-kernel@vger.kernel.org \
--cc=suresh.b.siddha@intel.com \
/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