lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <562C8D68.9040008@reserved-bit.com> Date: Sun, 25 Oct 2015 13:36:00 +0530 From: Siddhesh Poyarekar <sid@...erved-bit.com> To: "Suzuki K. Poulose" <suzuki.poulose@....com>, linux-arm-kernel@...ts.infradead.org Cc: catalin.marinas@....com, will.deacon@....com, mark.rutland@....com, dave.martin@....com, Vladimir.Murzin@....com, steve.capper@...aro.org, linux-kernel@...r.kernel.org, ard.biesheuvel@...aro.org, james.morse@....com, marc.zyngier@....com, christoffer.dall@...aro.org, andre.przywara@....com, edward.nevill@...aro.org, aph@...hat.com, ryan.arnold@...aro.org Subject: 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists