Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1255291 > unrolled thread

Re: [PATCH v3 00/24] arm64: Consolidate CPU feature handling

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3 00/24] arm64: Consolidate CPU feature handling Siddhesh Poyarekar <sid@reserved-bit.com> - 2015-10-25 09:20 +0100
    Re: [PATCH v3 00/24] arm64: Consolidate CPU feature handling "Suzuki K. Poulose" <Suzuki.Poulose@arm.com> - 2015-10-27 19:10 +0100
      Re: [PATCH v3 00/24] arm64: Consolidate CPU feature handling Siddhesh Poyarekar <sid@reserved-bit.com> - 2015-10-28 10:00 +0100

#1255291 — Re: [PATCH v3 00/24] arm64: Consolidate CPU feature handling

On Tuesday 13 October 2015 10:52 PM, Suzuki K. Poulose wrote:
> Apart from the selected feature registers, we expose MIDR_EL1 (Main
> ID Register). The user should be aware that, reading MIDR_EL1 can be
> tricky on a heterogeneous system (just like getcpu()). We export the
> value of the current CPU where 'MRS' is executed. REVIDR is not exposed
> via MRS, since we cannot guarantee atomic access to both MIDR and REVIDR
> (task migration). So they both are exposed via sysfs under :
> 
> 	/sys/devices/system/cpu/cpu$ID/identification/
> 							\- midr
> 							\- revidr
> 
> The ABI useful for the toolchains (e.g, gcc, dynamic linker, JIT) to make
> better runtime decisions based on what is available.

Thank you for doing this.  I'm prototyping glibc support to select
optimal functions by micro-architecture and I had a couple of concerns.

The midr emulation may not be sufficient for glibc to select optimal
routines because there could theoretically be sufficient variance
between cpus with only different revidr that vendors may write different
optimal routines.  Secondly, on a heterogeneous system, we won't be able
to select a routine reliably using just the emulated instruction since
we have no control where it runs and we would want to know what each of
the cpus looks like.

The sysfs API solves this problem, but it doesn't seem like an optimal
thing to do in an IFUNC resolver in glibc.  CPU information is scattered
in 2*N+1 files for N processor cores.  This means for every process, one
has to make 4*N+2 system calls to simply read in this information and
cache it for later decision making.  On a 64 core system, this would
mean making 258 additional system calls from within the IFUNC resolver,
which seems quite excessive.

Would you be able to consolidate all cpu identification into a single
file?  This would allow glibc to just map in the file and read in all of
the information in one go, greatly reducing the number of syscalls.

The other alternative I was thinking of was to have an additional hwcap
HWCAP_HETEROGENEOUS_CPU which is set if there are different kinds of
processor cores in the system, but that will force us to stick to
default routines for heterogeneous cores.

Siddhesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1257093

On 25/10/15 08:06, Siddhesh Poyarekar wrote:
> On Tuesday 13 October 2015 10:52 PM, Suzuki K. Poulose wrote:
>> Apart from the selected feature registers, we expose MIDR_EL1 (Main
>> ID Register). The user should be aware that, reading MIDR_EL1 can be
>> tricky on a heterogeneous system (just like getcpu()). We export the
>> value of the current CPU where 'MRS' is executed. REVIDR is not exposed
>> via MRS, since we cannot guarantee atomic access to both MIDR and REVIDR
>> (task migration). So they both are exposed via sysfs under :
>>
>> 	/sys/devices/system/cpu/cpu$ID/identification/
>> 							\- midr
>> 							\- revidr
>>
>> The ABI useful for the toolchains (e.g, gcc, dynamic linker, JIT) to make
>> better runtime decisions based on what is available.
>
> Thank you for doing this.  I'm prototyping glibc support to select
> optimal functions by micro-architecture and I had a couple of concerns.
>
> The midr emulation may not be sufficient for glibc to select optimal
> routines because there could theoretically be sufficient variance
> between cpus with only different revidr that vendors may write different
> optimal routines.

But then there is no way we can provide the midr/revidr pair reliably.
So I guess we can't do much about it.

>  Secondly, on a heterogeneous system, we won't be able
> to select a routine reliably using just the emulated instruction since
> we have no control where it runs and we would want to know what each of
> the cpus looks like.

On a heterogeneous system, we can't do much, as you will anyway need to know
which CPU you are running on to select the version, which itself is not
reliable (unless you are pinned to the CPU).

>
> The sysfs API solves this problem, but it doesn't seem like an optimal
> thing to do in an IFUNC resolver in glibc.  CPU information is scattered

I agree, the sysfs API is not suitable for low-level users like IFUNC, but
for tools like JIT to determine the CPUs present on the system.

>
> Would you be able to consolidate all cpu identification into a single
> file?  This would allow glibc to just map in the file and read in all of
> the information in one go, greatly reducing the number of syscalls.

I am afraid that would impose a new ABI with complications on how we
handle information about the CPUs in different states (online, offline,
etc). I am open to suggestions here.

>
> The other alternative I was thinking of was to have an additional hwcap
> HWCAP_HETEROGENEOUS_CPU which is set if there are different kinds of
> processor cores in the system, but that will force us to stick to
> default routines for heterogeneous cores.

See [1] for previous discussion on this topic.

[1] https://lkml.org/lkml/2015/9/1/391

Thanks
Suzuki

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1257807

On Tuesday 27 October 2015 11:39 PM, Suzuki K. Poulose wrote:
> I am afraid that would impose a new ABI with complications on how we
> handle information about the CPUs in different states (online, offline,
> etc). I am open to suggestions here.

No I agree it would be non-trivial to maintain this information in a
single file.  Nor does it solve my problem completely based on the
context you give below, so it's not worth spending time on.

> See [1] for previous discussion on this topic.
> 
> [1] https://lkml.org/lkml/2015/9/1/391

Thank you for the context.  Somehow I was expecting information for all
configured processors (as opposed to only online ones) to be available
at boot time inside sysfs, but clearly that is not going to happen.  Let
me see if I can think of a way to use this information in glibc.

Thanks,
Siddhesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web