From owner-freebsd-current@freebsd.org Tue Jan 2 01:27:03 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 4F41DEA7AD4 for ; Tue, 2 Jan 2018 01:27:03 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1337D67494; Tue, 2 Jan 2018 01:27:03 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x231.google.com with SMTP id c16so13222469itc.5; Mon, 01 Jan 2018 17:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OqH8zhDZnCu6Zysq5jYAoKvA+aypOyUHI2rlk1Oupp8=; b=eVqaXA9aEq+UaOYNYSpZMehtsbRNYnZT4qkS4HR7/n3mxBeL2m3ZQ+FVX65z4rW88I RZ5NAXZQtkAxkRDvAx7vNqsY33VjRsRiZClsMKZp9kLyJxrv7IhQfV8S4P8bmYZsyiPS Ru2M0dZDEWPSqhDFa03Uy0zfvBHKC/2X3CMli+jr1tb/R1QSNZOOye4btA8nYOwp7A2P OqWeuIPFgpPr7YtgNbz5XnWfwQ3qly+8yR5ODltnIJB/yJs9qCjcnumDzRtcRs2y/z+D dEy8ekZ1Ta/5Sg3JJ0XDRL824TsYTtraV68n1dgRztESFBEQq5J9rVfQC67aYLeI0yhW 5URg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OqH8zhDZnCu6Zysq5jYAoKvA+aypOyUHI2rlk1Oupp8=; b=PxDSTs+XWjieOqGrYqJOzsHonQtbUzFrWa2H/WnZVhLGB5AzcaK9jCsYvtWp7v8M1B xozAytWyD//rRWzCHRuXs671sEnH971PsnMobDBiSAZMiL1TSfaYSXG7XImLf/9r4dA5 WUwDeHOaQqj1yknYs1ZC/KhzBl+O+PlpM+Zy/osgYtWpiD2l28JjKJ9/oGAr9m0zJjIn liyIwiFi9SJE46fiD4fFGOrgVmxIQdpYgFSfn9byqY4ZXH/NJGtDkSeHweuQ8/FIva6U eQIR4xk+jID8qXweGTx7JVpMo/vS9UjB27BmZ4oyAZgMWNlm7MHRBflUmW6KuKLvFoIb 9Phg== X-Gm-Message-State: AKGB3mI94hDqYrRyESzoNshqPj9GhdHiZnNBD2EyHZOKuwmQsD9gdC9F hL+Z1sAI+z41+fdCkQZSD4nlnyo4embHJhGf8v3Fzm17 X-Google-Smtp-Source: ACJfBosCur2FW/qEyZKWnhKwtWCOQtinomep/Ru3Xhyqg90Gdyn/R9mEg6iNnHIh5zt48FfHJH33P5GlWCwkpjLZPxY= X-Received: by 10.36.221.147 with SMTP id t141mr56963359itf.140.1514856422197; Mon, 01 Jan 2018 17:27:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Mon, 1 Jan 2018 17:27:01 -0800 (PST) In-Reply-To: <1514823989.12000.30.camel@freebsd.org> References: <20171230082812.GL1684@kib.kiev.ua> <08038E36-9679-4286-9083-FCEDD637ADCC@FreeBSD.org> <20180101103655.GF1684@kib.kiev.ua> <1514823989.12000.30.camel@freebsd.org> From: blubee blubeeme Date: Tue, 2 Jan 2018 09:27:01 +0800 Message-ID: Subject: Re: Programmatically cache line To: Ian Lepore Cc: Konstantin Belousov , David Chisnall , Adrian Chadd , FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Tue, 02 Jan 2018 01:27:03 -0000 On Tue, Jan 2, 2018 at 12:26 AM, Ian Lepore 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 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 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?