Re: malloc, thread and alignment

["Jean-Yves Migeon (NetBSD)" <jym%NetBSD.org@localhost>]

Le 27/03/2015 17:38, Taylor R Campbell a écrit :
> Date: Fri, 27 Mar 2015 16:30:32 +0100
>    From: "Jean-Yves Migeon (NetBSD)" <jym%NetBSD.org@localhost>
>
>    For x86 you can look at cpuctl(8), identifycpu() uses cpuid to get 
> this
>    information. This is MD and varies between AMD/Intel, revisions... 
> This
>    requires not-so-funny tests to deduce the correct value. I don't 
> think
>    this is exposed through headers/libs for external use though.
>
>    AFAICT !x86 platforms have nothing.
>
> Perhaps we ought to expose it via a sysctl.

or sysconf(3)

> Someone^TM should document the kernel CACHE_LINE_SIZE, coherency_unit,
> COHERENCY_UNIT, and figure out what it is worthwhile to expose MI to
> userland.  Obviously some systems may have different instruction and
> data cache line sizes, and maybe there are more exotic possibilities,
> but presumably there is a good conservative estimate for user programs
> to round buffers to.  jemalloc seems to use 64 bytes unconditionally.

Maybe 64 bytes is the good conservative estimate then :) (which is not 
far away from reality)

Making that stuff MI "one size fits all" is tough. Looking back at 
cpuctl(8), I have always seen multiple possibilities for a userland 
binary to query that kind of information from the system: sysctl(3), 
sysconf(3), or specifically-crafted-structs passed to an ioctl(2) (like 
cpuctl). What governs the choice of an interface over another there?

(and yes, I know about proplib or Linux /sys)

--
Jean-Yves Migeon
jym@