Re: Programmatically cache line

From: Ian Lepore <ian_at_freebsd.org>
Date: Mon, 01 Jan 2018 09:26:29 -0700
On Mon, 2018-01-01 at 12:36 +0200, Konstantin Belousov wrote:
> On Mon, Jan 01, 2018 at 06:52:37AM +0000, David Chisnall wrote:
> > 
> > On 1 Jan 2018, at 05:09, Adrian Chadd <adrian.chadd_at_gmail.com> wrote:
> > > 
> > > 
> > > On 30 December 2017 at 00:28, Konstantin Belousov  wrote:
> > > > 
> > > > On Sat, Dec 30, 2017 at 07:50:19AM +0000, blubee blubeeme wrote:
> > > > > 
> > > > > Is there some way to programmatically get the CPU cache line sizes on
> > > > > FreeBSD?
> > > > There are, all of them are MD.
> > > > 
> > > > On x86, the CPUID instruction leaf 0x1 returns the information in
> > > > %ebx register.
> > > Hm, weird. Why don't we extend sysctl to include this info?
> For the same reason we do not provide a sysctl to add two integers.
> 
> > 
> > 
> > It would be nice to expose this kind of information via VDSO or similar.  There are a lot of similar bits of info that people want to use for ifunc and, SVE is going to have a bunch of similar requirements.
> > 
> Is VDSO a new trendy word ?
> 
> ifunc resolvers in usermode on FreeBSD/x86 get four arguments which
> are essentially cpu_features / cpu_features2 / cpu_stdext_features /
> cpu_stdext_features2.  I suspect that only FreeBSD/x86 arches have the
> ifunc support, in rtld and coming shortly in kernel.
> 
> Recently HW_CAP/HW_CAP2 were added to the ELF auxv, and elf_aux_info(3)
> interface exported from libc.
> 
> ARM* did not implemented yet the ifunc stubs in rtld. I believe this is
> considered a low priority because there is no ready to use toolchain
> which allow to utilize ifuncs on FreeBSD, except if you use recent bfd
> ld externally.

Linux exports this info using getauxval().  I think we should support
getauxval() and as many of the AT_* values that linux defines as makes
sense for us to do.

I think it was a mistake to give our version of the function a
different name and different semantics, but this is something that
affects mainly ports, and I don't yet have enough info to make the case
that being linux-compatible will ease porting rather than complicate it
(in some cases, patches will be needed either way).

-- Ian
Received on Mon Jan 01 2018 - 15:26:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:14 UTC