From owner-freebsd-current@freebsd.org Mon Jan 1 16:26:45 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3323EB1404 for ; Mon, 1 Jan 2018 16:26:45 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D39D72874 for ; Mon, 1 Jan 2018 16:26:44 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 86e3e4cf-ef10-11e7-8dac-d32f5c2d02ef X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 86e3e4cf-ef10-11e7-8dac-d32f5c2d02ef; Mon, 01 Jan 2018 16:26:33 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w01GQTFL010561; Mon, 1 Jan 2018 09:26:29 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1514823989.12000.30.camel@freebsd.org> Subject: Re: Programmatically cache line From: Ian Lepore To: Konstantin Belousov , David Chisnall Cc: Adrian Chadd , blubee blubeeme , FreeBSD current Date: Mon, 01 Jan 2018 09:26:29 -0700 In-Reply-To: <20180101103655.GF1684@kib.kiev.ua> References: <20171230082812.GL1684@kib.kiev.ua> <08038E36-9679-4286-9083-FCEDD637ADCC@FreeBSD.org> <20180101103655.GF1684@kib.kiev.ua> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 16:26:45 -0000 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 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