Re: Programmatically cache line

On Tue, Jan 2, 2018 at 12:26 AM, Ian Lepore <ian_at_freebsd.org> wrote:

> 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
>
FreeBSD implements hardware specific atomic instructions [man atomic] or
look at: #include <machine/atomic.h>

but implementing something that returns size of cache lines is somehow out
of the question?

If you're working with atomic data structures and want to ensure there's no
false sharing the
simplest method I know is to put some padding that's sizeof(cache_line) -
sizeof(data_members)
so that you can try to get them to live on different cache line.

Do we have to go in and write inline assembly to grab the size of the cache
line or wouldn't it
be simpler to have atomic.h return this info?