Re: Wrong number of core_siblings in sysfs for Athlon64 X2

[Zan Lynx <zlynx@acm.org>]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

On Thu, 2006-02-16 at 23:08 +0100, Jesper Juhl wrote:
> On 2/16/06, Andi Kleen <ak@suse.de> wrote:
> > On Thursday 16 February 2006 22:46, Jesper Juhl wrote:
> >
> > > Obviously something is wrong, but I just can't seem to spot it.  Any clues?
> >
> > It's a bitmap. 3 = 0b11
> >
> 
> When I was reading the smpboot code my brain *was* actually in the
> "this is a bitmap" mode, but when I then looked at the sysfs code it
> for some reason switched to "this wants to just print the number of
> siblings as an integer" mode - which was obviously where I went wrong.
> If it's being treated as a bitmap when it's created why would that
> change when it gets printed - D'OH!
> 
> Thank you very much for that hit with the clue stick Andi.

While looking around for other examples, I ran across
cpufreq/affected_cpus.  Shouldn't cpufreq.c:show_affected_cpus() be
using cpumask_scnprintf instead of "%u"?

But anyway...

It seems to me that this could be confusing for a lot of people who are
casually browsing through sysfs.  Why not name core_siblings something
like core_sibling_bitmap?  Using _units isn't unprecedented, we have
read_ahead_kb.  I think it's nice not having to look it up to know
read_ahead is in kb and not bytes or sectors.  Likewise, it'd be nice to
know it's a bitmap and not a count just by looking at the name.

More alternatively, bitmaps seem ugly.  Why not one of these options
instead?
- a space separated list of bitmap offsets: "0 1" instead of 3
- a directory of symlinks to devices/system/cpu/cpu[N]:
   devices/system/cpu/cpu1/topology/core_siblings/0 -> ../../../cpu0
   devices/system/cpu/cpu1/topology/core_siblings/1 -> ../../../cpu1
-- 
Zan Lynx <zlynx@acm.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]