From owner-freebsd-current@freebsd.org Wed Jan 3 09:41:42 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 6D5FAEB66F4 for ; Wed, 3 Jan 2018 09:41:42 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 387F36C0DC; Wed, 3 Jan 2018 09:41:42 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: by mail-pg0-x233.google.com with SMTP id i5so503396pgq.11; Wed, 03 Jan 2018 01:41:42 -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=aegDIOmqRLSKtApc268aSp5rycucmG3hwrFMBY3gqe8=; b=D33x/gHy9SJvHdFwX7pC070XSJ0ahg7agtvtyEfS2K2d56sUGU62JrEx0tdQLE/7x8 eYedFhYsvyYQMwZx4l3ZE3HdY+nYlhv0lNrXWO3z7ZoDf8mGro/ZeiIDZbqWbQdAYtAD 2bUhDR/bgWxWSZY0vfwu9m8vvgeI9BFqCjTnTa+JWiaXOReaCIGwEQRcYIITFlloFPQ7 g5j/G0KOGd61hMDgfRM0LO8gn8ULMHgSbp3VsBIY83hqkfAEy9z6QIoNVrqrdUTFtEV1 e0UaIiAszTAQ3C3dRixXK7HLcoTw3GEuODAnwmrF433BWaG7mCTmwwYS1jV/MwiWED86 8GdA== 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=aegDIOmqRLSKtApc268aSp5rycucmG3hwrFMBY3gqe8=; b=SvwbGIHJhOAOqdmSSaJ5Nc7Zn4izOdztlMgfkn0PxFkEd5iyvXvFIPYZZVz4QC+sRG dYhpAx65xj0mlyD8+0qd81XUo6wHknv7eOBjLZuh3GSlmkWkimDFIKIAchCwUOi/qKpN CLvBfrUn0wi1F+i7a04vo8x3XHWDy/WTiyTZETWHexZLav0OX38EsG+YezHq1DxKhVOs +bwv2HC7Fcnh4RiteEN+UGthl+VIQESKp2jrSYx3chZEXJmXJK+yVgEC/HmoZCRQWyh9 O9tAtq5YKFObyx8ogF+1afCgo8bGKlnNxqqKKSD78czyMNyVcwVLsbhBtggwuA7TRQir ucFw== X-Gm-Message-State: AKGB3mIZAJUBQ1RKW/qf+ZDWHuPRrCo1ZNIlmg0nNj7CK00AsF9SzCrT Uv6SvSPKfq2ON0q8ZqLj3wenYq/ARN9tBcGuItZE/w== X-Google-Smtp-Source: ACJfBovEziYKRUUV9me6BO2I6A0roMh1G3PQYBXYqqWve3bu2JTGcVnxgeQqamLihWtQM25bRyG+IKeaMb/rWsf1H70= X-Received: by 10.98.19.202 with SMTP id 71mr865759pft.181.1514972501666; Wed, 03 Jan 2018 01:41:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.130 with HTTP; Wed, 3 Jan 2018 01:41:41 -0800 (PST) In-Reply-To: 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: Maurizio Vairani Date: Wed, 3 Jan 2018 10:41:41 +0100 Message-ID: Subject: Re: Programmatically cache line To: blubee blubeeme Cc: Ian Lepore , 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: Wed, 03 Jan 2018 09:41:42 -0000 2018-01-02 2:27 GMT+01:00 blubee blubeeme : > 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? > > You can use CPUCTL(4).