All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: discuss@x86-64.org
Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>,
	linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [discuss] [Patch 1/2] x86, x86_64: Intel HT, Multi core detection fixes
Date: Wed, 12 Oct 2005 23:49:04 +0200	[thread overview]
Message-ID: <200510122349.05312.ak@suse.de> (raw)
In-Reply-To: <20051012143641.B29292@unix-os.sc.intel.com>

On Wednesday 12 October 2005 23:36, Siddha, Suresh B wrote:

> Fields obtained through cpuid vector 0x1(ebx[16:23]) and
> vector 0x4(eax[14:25], eax[26:31]) indicate the maximum values and might not
> always be the same as what is available and what OS sees.  So make sure
> "siblings" and "cpu cores" values in /proc/cpuinfo reflect the values as seen
> by OS instead of what cpuid instruction says. This will also fix the buggy BIOS
> cases (for example where cpuid on a single core cpu says there are "2" siblings,
> even when HT is disabled in the BIOS. 
> http://bugzilla.kernel.org/show_bug.cgi?id=4359)

I'm not too fond of this new booted_core variable. How about
you just put the true number of cores into x86_num_cores? 
What should x86_num_cores be in your setup anyways if not
"booted cores"? 

Also I must admit the number of different variables to keep
track of multicore and siblingness starts to become mindboggling,
so I would recommend you add a fat overview comment somewhere
that describes their definition and relationship. Or better put
something into Documentation, it is probably as confusing for 
user space /proc/cpuinfo consumer too.

-Andi

  reply	other threads:[~2005-10-12 21:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-05 23:17 [Patch] x86, x86_64: Intel HT, Multi core detection code cleanup Siddha, Suresh B
2005-10-06 10:42 ` Andi Kleen
2005-10-07  2:20   ` Siddha, Suresh B
2005-10-07  9:52     ` [discuss] " Andi Kleen
2005-10-08  0:52       ` Siddha, Suresh B
2005-10-08 10:28         ` Andi Kleen
2005-10-12 21:30           ` Siddha, Suresh B
2005-10-12 21:36           ` [Patch 1/2] x86, x86_64: Intel HT, Multi core detection fixes Siddha, Suresh B
2005-10-12 21:49             ` Andi Kleen [this message]
2005-10-12 22:19               ` [discuss] " Siddha, Suresh B
2005-10-13  0:10                 ` Andi Kleen
2005-10-13 21:55                   ` Siddha, Suresh B
2005-10-13 21:59                   ` [Patch 2/2] x86, x86_64: fix Intel cache detection code assumption about threads sharing Siddha, Suresh B
2005-10-12 21:41           ` Siddha, Suresh B

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=200510122349.05312.ak@suse.de \
    --to=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=discuss@x86-64.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.