[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/2] add cpu_thread_id to struct cpuinfo_x86



>>> On 03.09.18 at 17:11, <jgross@xxxxxxxx> wrote:
> On 03/09/18 17:07, Jan Beulich wrote:
>>>>> On 03.09.18 at 16:52, <jgross@xxxxxxxx> wrote:
>>> On 03/09/18 16:47, Jan Beulich wrote:
>>>>>>> On 03.09.18 at 15:53, <jgross@xxxxxxxx> wrote:
>>>>> On 03/09/18 15:46, Jan Beulich wrote:
>>>>>>>>> On 31.08.18 at 18:22, <jgross@xxxxxxxx> wrote:
>>>>>>> Add the thread-id to the cpu config data and an accessor macro
>>>>>>> cpu_to_thread().
>>>>>>>
>>>>>>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
>>>>>>> ---
>>>>>>>  xen/arch/x86/cpu/common.c       |  1 +
>>>>>>>  xen/arch/x86/smpboot.c          | 10 ++++++++++
>>>>>>>  xen/include/asm-arm/processor.h |  1 +
>>>>>>>  xen/include/asm-x86/processor.h |  2 ++
>>>>>>>  xen/include/public/sysctl.h     |  1 +
>>>>>>>  5 files changed, 15 insertions(+)
>>>>>>>
>>>>>>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>>>>>>> index 057859ab14..f626a6a510 100644
>>>>>>> --- a/xen/arch/x86/cpu/common.c
>>>>>>> +++ b/xen/arch/x86/cpu/common.c
>>>>>>> @@ -434,6 +434,7 @@ void identify_cpu(struct cpuinfo_x86 *c)
>>>>>>>         c->phys_proc_id = XEN_INVALID_SOCKET_ID;
>>>>>>>         c->cpu_core_id = XEN_INVALID_CORE_ID;
>>>>>>>         c->compute_unit_id = INVALID_CUID;
>>>>>>> +       c->cpu_thread_id = XEN_INVALID_THREAD_ID;
>>>>>>>         memset(&c->x86_capability, 0, sizeof c->x86_capability);
>>>>>>>  
>>>>>>>         generic_identify(c);
>>>>>>> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
>>>>>>> index 7e76cc3d68..2c6a40c543 100644
>>>>>>> --- a/xen/arch/x86/smpboot.c
>>>>>>> +++ b/xen/arch/x86/smpboot.c
>>>>>>> @@ -247,6 +247,8 @@ static void set_cpu_sibling_map(unsigned int cpu)
>>>>>>>      cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
>>>>>>>      cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
>>>>>>>  
>>>>>>> +    c[cpu].cpu_thread_id = 0;
>>>>>>> +
>>>>>>>      if ( c[cpu].x86_num_siblings > 1 )
>>>>>>>      {
>>>>>>>          for_each_cpu ( i, &cpu_sibling_setup_map )
>>>>>>> @@ -270,6 +272,14 @@ static void set_cpu_sibling_map(unsigned int cpu)
>>>>>>>                         "CPU%u: unclear relationship with CPU%u\n",
>>>>>>>                         cpu, i);
>>>>>>>          }
>>>>>>> +
>>>>>>> +        for_each_cpu ( i, per_cpu(cpu_sibling_mask, cpu) )
>>>>>>> +        {
>>>>>>> +            if ( cpu == i )
>>>>>>> +                break;
>>>>>>> +            c[cpu].cpu_thread_id++;
>>>>>>
>>>>>> No. This wants doing alongside setting of the other similar fields,
>>>>>> i.e. in (at least) detect_extended_topology() and detect_ht(). It
>>>>>> is the hardware which tells us what the thread ID is.
>>>>>
>>>>> I wasn't able to find the related information for AMD cpus. In case it
>>>>> is in the specs it is hidden very well.
>>>>
>>>> What was used for compute units in Fam16 and earlier is used for
>>>> hyperthreads in Fam17 (and going forward, from what iirc Brian
>>>> has said).
>>>
>>> And what about hyperthreads in Fam16 and earlier? Or are "compute units"
>>> just another name for the threads and I can rename that field?
>> 
>> When there are compute units, there are no threads. But the difference
>> is more than just the names, so folding the fields is not a good idea imo.
> 
> So another flag and display the column title accordingly?
> 
> I'd put thread and compute unit in a union then.

Both fine with me.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.