[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160712191049.GB27918@gallifrey>
Date: Tue, 12 Jul 2016 20:10:49 +0100
From: "Dr. David Alan Gilbert" <dave@...blig.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "H. Peter Anvin" <hpa@...or.com>, paulmck@...ux.vnet.ibm.com,
tglx@...utronix.de, mingo@...e.hu, ak@...ux.intel.com,
linux-kernel@...r.kernel.org
Subject: Re: [CRM114spam]: Re: Odd performance results
* Peter Zijlstra (peterz@...radead.org) wrote:
> On Tue, Jul 12, 2016 at 10:49:58AM -0700, H. Peter Anvin wrote:
> > On 07/12/16 08:05, Paul E. McKenney wrote:
> > The CPU in question (and /proc/cpuinfo should show this) has four cores
> > with a total of eight threads. The "siblings" and "cpu cores" fields in
> > /proc/cpuinfo should show the same thing. So I am utterly confused
> > about what is unexpected here?
>
> Typically threads are enumerated differently on Intel parts. Namely:
>
> cpu_id = code_id + nr_cores * smt_id
>
> which gives, for a 4 core, 2 thread part:
>
> 0-3: core 0-3, smt0
> 4-7: core 0-3, smt1
>
> My Core i7-2600k for example has:
>
> $ cat /sys/devices/system/cpu/cpu*/topology/thread_siblings_list
> 0,4
> 1,5
> 2,6
> 3,7
> 0,4
> 1,5
> 2,6
> 3,7
>
> The ordering Paul has, namely 0,1 for core0,smt{0,1} is not something
> I've ever seen on an Intel part. AMD otoh does enumerate their CMT stuff
> like what Paul has.
Paul's isn't unique:
cat /sys/devices/system/cpu/cpu*/topology/thread_siblings_list
0-1
0-1
2-3
2-3
i7-3520M CPU @ 2.90GHz (Dual core with hyperthread, Thinkpad t530, fedora 24)
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
Powered by blists - more mailing lists