public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Distinguish real vs. virtual CPUs?
Date: Wed, 23 Mar 2005 16:32:10 -0500	[thread overview]
Message-ID: <d1sm6q$5po$1@gatekeeper.tmr.com> (raw)
In-Reply-To: <20050323175226.GB3272@zero>

Tom Vier wrote:
> On Tue, Mar 22, 2005 at 04:26:47PM -0500, Bill Davidsen wrote:
> 
>>It's not clear if that's bizarre practice on AMD system boards or if 
>>it's mis-reported. Of course Tom may be running a NUMA setup, in which 
>>case I won't guess what's expected to be displayed. I've added him to 
>>the CC list, in hopes of comment.
> 
> 
> It's numa (two cores, one ram ctrlr per core, one core per package). I'm
> running an x86 kernel, btw, not 64bit. I have CONFIG_X86_HT set, and it
> looks like it gets the pkg id from the apic (there's only one in multicore
> packages?), but i might be reading it wrong.
> 
> My dmseg overflows before syslog starts, so all i could gather is: 

Thanks, Tom. I suspect that NUMA has issues of its own in this area. I 
always set up the kernel buffer size and run dmesg with -s200000 or so 
on machines which tend to be overly verbose.

I leave it to someone really expert to figure out how to tell the actual 
number of sockets, cores, and siblings. I think the system scheduler may 
want this info, but I certainly don't intend to start 2nd guessing the 
kernel on this stuff. The current scheduler does a pretty good job of 
handling HT now, I'm not about to try and do better.

Interesting thought, I believe the IBM chip for PS not only has many 
cores, but one article said they were not all the same. That, and 
thoughts of someone running an SMP system with chips having 
non-identical sibling count make me glad someone else is doing the 
scheduler.
> 
> Mar 23 12:04:25 zero kernel: Brought up 2 CPUs
> Mar 23 12:04:25 zero kernel: CPU0 attaching sched-domain:
> Mar 23 12:04:25 zero kernel:  domain 0: span 3
> Mar 23 12:04:25 zero kernel:   groups: 1 2
> Mar 23 12:04:25 zero kernel: CPU1 attaching sched-domain:
> Mar 23 12:04:25 zero kernel:  domain 0: span 3
> Mar 23 12:04:25 zero kernel:   groups: 2 1
> 
> I don't know how the scheduling domains work, and i'm too busy to look it up
> right now.
> 


-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

  reply	other threads:[~2005-03-23 21:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-22  4:29 Distinguish real vs. virtual CPUs? Pallipadi, Venkatesh
2005-03-22 21:26 ` Bill Davidsen
2005-03-22 21:38   ` Jan Engelhardt
2005-03-23 17:52   ` Tom Vier
2005-03-23 21:32     ` Bill Davidsen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-03-22  1:27 Dan Maas
2005-03-22  1:56 ` Dave Jones
2005-03-22 11:55   ` Dr. David Alan Gilbert
2005-03-22  2:01 ` Daniel Andersen
2005-03-22  2:12 ` J.A. Magallon

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='d1sm6q$5po$1@gatekeeper.tmr.com' \
    --to=davidsen@tmr.com \
    --cc=linux-kernel@vger.kernel.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