cpuinfo_x86 and apicid

cpuinfo_x86 and apicid

[Stephane Eranian]

Hello,


In the context of the perfmon2 subsystem for processor with HyperThreading,
we need to know on which thread we are currently running. This comes from
the fact that the performance counters are shared between the two threads.

We use the thread id (smt_id) because we split the counters in half
between the two threads such that two threads on the same core can run
with monitoring on.  We are currently computing the smt_id from the
apicid as returned by a CPUID instruction. This is not very efficient.

I looked through the i386 code and could not find a function nor 
structure that would return this smt_id. In the cpuinfo_x86 structure
there is an apicid field that looks good, yet it does not seem to be
initialized nor used.

Is cpuinfo_x86->apicid field obsolete? 
If so, what is replacing it?

Thanks.

-- 
-Stephane

Re: cpuinfo_x86 and apicid

[linux-os (Dick Johnson)]

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


On Thu, 6 Jul 2006, Stephane Eranian wrote:

> Hello,
>
>
> In the context of the perfmon2 subsystem for processor with HyperThreading,
> we need to know on which thread we are currently running. This comes from
> the fact that the performance counters are shared between the two threads.
>
> We use the thread id (smt_id) because we split the counters in half
> between the two threads such that two threads on the same core can run
> with monitoring on.  We are currently computing the smt_id from the
> apicid as returned by a CPUID instruction. This is not very efficient.
>
> I looked through the i386 code and could not find a function nor
> structure that would return this smt_id. In the cpuinfo_x86 structure
> there is an apicid field that looks good, yet it does not seem to be
> initialized nor used.
>
> Is cpuinfo_x86->apicid field obsolete?
> If so, what is replacing it?
>
> Thanks.
>
> --
> -Stephane
> -

Does the attached file help? It is supposed to tell which CPU
execution is occurring on. This might be modified to fill your
needs.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.88 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

[-- Attachment #2: whichcpu.c --]
[-- Type: TEXT/PLAIN, Size: 874 bytes --]

/*
 *  This program tells you what CPU your process is executing on.
 *  If you comment-out the usleep(10000), so you are eating all the
 *  CPU time in your time-slice, and you execute this from two tasks,
 *  you will note that each task gets its own CPU if you have two
 *  CPUs.
 *  If you leave in the usleep(), you will note that both tasks may
 *  use the same CPU. This happens if, and only if, they are not
 *  executing at the same time.
 */ 


#include <stdio.h>
int main(void);

int main()
{
    int cpu, prv;
    prv = -1; 
    for(;;)
    {
        __asm__ __volatile__ (
		"xorl %%eax,%%eax\n"
		"str %%ax\n"
		"subl $0x60, %%eax\n"
		"shrl $0x05, %%eax\n"
		: "=a"(cpu));
        if(cpu != prv)
        {
            prv = cpu;
            printf("CPU %d\n", cpu);
        }
        usleep(10000);
    }
    return 0;
}

Re: cpuinfo_x86 and apicid

[Siddha, Suresh B]

On Thu, Jul 06, 2006 at 08:01:18AM -0700, Stephane Eranian wrote:
> Hello,
> 
> 
> In the context of the perfmon2 subsystem for processor with HyperThreading,
> we need to know on which thread we are currently running. This comes from
> the fact that the performance counters are shared between the two threads.
> 
> We use the thread id (smt_id) because we split the counters in half
> between the two threads such that two threads on the same core can run
> with monitoring on.  We are currently computing the smt_id from the
> apicid as returned by a CPUID instruction. This is not very efficient.
> 
> I looked through the i386 code and could not find a function nor 
> structure that would return this smt_id. In the cpuinfo_x86 structure
> there is an apicid field that looks good, yet it does not seem to be
> initialized nor used.
> 
> Is cpuinfo_x86->apicid field obsolete? 
> If so, what is replacing it?

In i386, it is getting initialized in generic_identify() in common.c and
it is getting used for example in intel_cacheinfo.c

thanks,
suresh

Re: cpuinfo_x86 and apicid

[Stephane Eranian]

On Thu, Jul 06, 2006 at 09:19:30AM -0700, Siddha, Suresh B wrote:
> On Thu, Jul 06, 2006 at 08:01:18AM -0700, Stephane Eranian wrote:
> > Hello,
> > 
> > 
> > In the context of the perfmon2 subsystem for processor with HyperThreading,
> > we need to know on which thread we are currently running. This comes from
> > the fact that the performance counters are shared between the two threads.
> > 
> > We use the thread id (smt_id) because we split the counters in half
> > between the two threads such that two threads on the same core can run
> > with monitoring on.  We are currently computing the smt_id from the
> > apicid as returned by a CPUID instruction. This is not very efficient.
> > 
> > I looked through the i386 code and could not find a function nor 
> > structure that would return this smt_id. In the cpuinfo_x86 structure
> > there is an apicid field that looks good, yet it does not seem to be
> > initialized nor used.
> > 
> > Is cpuinfo_x86->apicid field obsolete? 
> > If so, what is replacing it?
> 
> In i386, it is getting initialized in generic_identify() in common.c and
> it is getting used for example in intel_cacheinfo.c
> 
Well, yes this is exactly what I want, except that it is not compiled for x86_64
so on a HT Xeon in 64-bit I don't get it. Why is that?

-- 

-Stephane

Re: cpuinfo_x86 and apicid

[Siddha, Suresh B]

On Thu, Jul 06, 2006 at 01:00:31PM -0700, Stephane Eranian wrote:
> On Thu, Jul 06, 2006 at 09:19:30AM -0700, Siddha, Suresh B wrote:
> > On Thu, Jul 06, 2006 at 08:01:18AM -0700, Stephane Eranian wrote:
> > > Hello,
> > > 
> > > 
> > > In the context of the perfmon2 subsystem for processor with HyperThreading,
> > > we need to know on which thread we are currently running. This comes from
> > > the fact that the performance counters are shared between the two threads.
> > > 
> > > We use the thread id (smt_id) because we split the counters in half
> > > between the two threads such that two threads on the same core can run
> > > with monitoring on.  We are currently computing the smt_id from the
> > > apicid as returned by a CPUID instruction. This is not very efficient.
> > > 
> > > I looked through the i386 code and could not find a function nor 
> > > structure that would return this smt_id. In the cpuinfo_x86 structure
> > > there is an apicid field that looks good, yet it does not seem to be
> > > initialized nor used.
> > > 
> > > Is cpuinfo_x86->apicid field obsolete? 
> > > If so, what is replacing it?
> > 
> > In i386, it is getting initialized in generic_identify() in common.c and
> > it is getting used for example in intel_cacheinfo.c
> > 
> Well, yes this is exactly what I want, except that it is not compiled for x86_64
> so on a HT Xeon in 64-bit I don't get it. Why is that?

on x86_64, it is getting initialized in identify_cpu() and further
intel_cacheinfo.c gets linked in both i386 and x86_64.

thanks,
suresh

Re: cpuinfo_x86 and apicid

[Stephane Eranian]

Suresh,

On Thu, Jul 06, 2006 at 02:06:13PM -0700, Siddha, Suresh B wrote:
> On Thu, Jul 06, 2006 at 01:00:31PM -0700, Stephane Eranian wrote:
> > On Thu, Jul 06, 2006 at 09:19:30AM -0700, Siddha, Suresh B wrote:
> > > On Thu, Jul 06, 2006 at 08:01:18AM -0700, Stephane Eranian wrote:
> > > > Hello,
> > > > 
> > > > 
> > > > In the context of the perfmon2 subsystem for processor with HyperThreading,
> > > > we need to know on which thread we are currently running. This comes from
> > > > the fact that the performance counters are shared between the two threads.
> > > > 
> > > > We use the thread id (smt_id) because we split the counters in half
> > > > between the two threads such that two threads on the same core can run
> > > > with monitoring on.  We are currently computing the smt_id from the
> > > > apicid as returned by a CPUID instruction. This is not very efficient.
> > > > 
> > > > I looked through the i386 code and could not find a function nor 
> > > > structure that would return this smt_id. In the cpuinfo_x86 structure
> > > > there is an apicid field that looks good, yet it does not seem to be
> > > > initialized nor used.
> > > > 
> > > > Is cpuinfo_x86->apicid field obsolete? 
> > > > If so, what is replacing it?
> > > 
> > > In i386, it is getting initialized in generic_identify() in common.c and
> > > it is getting used for example in intel_cacheinfo.c
> > > 
> > Well, yes this is exactly what I want, except that it is not compiled for x86_64
> > so on a HT Xeon in 64-bit I don't get it. Why is that?
> 
> on x86_64, it is getting initialized in identify_cpu() and further
> intel_cacheinfo.c gets linked in both i386 and x86_64.
> 
Ah, yes I missed that. It works there two. I had something wrong
about how I accessed cpu_data. I am used to the elegant way we
do it on IA-64 but on x86_64 you have to index the cpu_data[]
array with smp_processor_id(). I was pointing to cpu_data[0]
on all processors.

For what I need, I can do cpuinfo_x86->apicid & 0x3 to identify
which thread is running. I can now remove some more code in perfmon2.

Thanks for your help.

-- 
-Stephane

Re: [perfmon] Re: cpuinfo_x86 and apicid

[Stephane Eranian]

Suresh,

On Thu, Jul 06, 2006 at 03:25:43PM -0700, Stephane Eranian wrote:
> > 
> Ah, yes I missed that. It works there two. I had something wrong
> about how I accessed cpu_data. I am used to the elegant way we
> do it on IA-64 but on x86_64 you have to index the cpu_data[]
> array with smp_processor_id(). I was pointing to cpu_data[0]
> on all processors.
> 
> For what I need, I can do cpuinfo_x86->apicid & 0x3 to identify
> which thread is running. I can now remove some more code in perfmon2.
> 
I meant cpuinfo_x86->apicid & 0x1.


-- 

-Stephane

Re: [perfmon] Re: cpuinfo_x86 and apicid

[Siddha, Suresh B]

On Thu, Jul 06, 2006 at 03:37:45PM -0700, Stephane Eranian wrote:
> Suresh,
> 
> On Thu, Jul 06, 2006 at 03:25:43PM -0700, Stephane Eranian wrote:
> > > 
> > Ah, yes I missed that. It works there two. I had something wrong
> > about how I accessed cpu_data. I am used to the elegant way we
> > do it on IA-64 but on x86_64 you have to index the cpu_data[]
> > array with smp_processor_id(). I was pointing to cpu_data[0]
> > on all processors.
> > 
> > For what I need, I can do cpuinfo_x86->apicid & 0x3 to identify
> > which thread is running. I can now remove some more code in perfmon2.
> > 
> I meant cpuinfo_x86->apicid & 0x1.

Instead of hard coding, can you get the size of the mask runtime from the
size of cpu_sibling_map[cpu]

And remember, physical/logical hotplug can change this sibling map.

thanks,
suresh