From owner-svn-src-head@FreeBSD.ORG Sat Mar 21 16:35:43 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A70851A0; Sat, 21 Mar 2015 16:35:43 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E006AC4; Sat, 21 Mar 2015 16:35:43 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2LGZaag054873 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 21 Mar 2015 18:35:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2LGZaag054873 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2LGZaRb054872; Sat, 21 Mar 2015 18:35:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 21 Mar 2015 18:35:36 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: svn commit: r280279 - head/sys/sys Message-ID: <20150321163536.GK2379@kib.kiev.ua> References: <201503201027.t2KAR6Ze053047@svn.freebsd.org> <20150320130216.GS2379@kib.kiev.ua> <550D9699.7070703@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550D9699.7070703@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 16:35:43 -0000 On Sat, Mar 21, 2015 at 12:04:41PM -0400, John Baldwin wrote: > On 3/20/15 9:02 AM, Konstantin Belousov wrote: > > On Fri, Mar 20, 2015 at 10:27:06AM +0000, John Baldwin wrote: > >> Author: jhb > >> Date: Fri Mar 20 10:27:06 2015 > >> New Revision: 280279 > >> URL: https://svnweb.freebsd.org/changeset/base/280279 > >> > >> Log: > >> Expand the bitcount* API to support 64-bit integers, plain ints and longs > >> and create a "hidden" API that can be used in other system headers without > >> adding namespace pollution. > >> - If the POPCNT instruction is enabled at compile time, use > >> __builtin_popcount*() to implement __bitcount*(), otherwise fall back > >> to software implementations. > > Are you aware of the Haswell errata HSD146 ? I see the described behaviour > > on machines back to SandyBridge, but not on Nehalems. > > HSD146. POPCNT Instruction May Take Longer to Execute Than Expected > > Problem: POPCNT instruction execution with a 32 or 64 bit operand may be > > delayed until previous non-dependent instructions have executed. > > > > Jilles noted that gcc head and 4.9.2 already provides a workaround by > > xoring the dst register. I have some patch for amd64 pmap, see the end > > of the message. > > No, I was not aware, but I think it's hard to fix this anywhere but the > compiler. I set CPUTYPE in src.conf on my Ivy Bridge desktop and clang > uses POPCOUNT for this function from ACPI-CA: > > static UINT8 > AcpiRsCountSetBits ( > UINT16 BitField) > { > UINT8 BitsSet; > > > ACPI_FUNCTION_ENTRY (); > > > for (BitsSet = 0; BitField; BitsSet++) > { > /* Zero the least significant bit that is set */ > > BitField &= (UINT16) (BitField - 1); > } > > return (BitsSet); > } > > (I ran into this accidentally because a kernel built on my system failed > to boot in older qemu because the kernel paniced with an illegal instruction > fault in this function.) > > There's no way we can preemptively locate every bit of C that clang might > decide to replace with popcount and fix them to employ a workaround. I think > the only viable solution is to use "-mno-popcount" on all compilers that aren't > known to be fixed. Both you and Bruce and Jilles state this, but I am unable to understand the argument about the compiler. Can somebody explain this to me, please ? Compiler cannot generate popcntq instructions unless it is directed to generate code not for amd64, but for some specific microacrchitecture. Any use of bitcount in generic kernel or userspace is going to be a SWAR. In other words, #ifdef __POPCNT__ is for non-default settings of the FreeBSD compilation environment. And even then, compiler must issue cpuid to fetch the feature mask, which arguably compiler cannot do due to the serialization instruction cost. Compiler could generate the call to instruction in the init code, but this is impossible for freestanding environment, since compiler does not know where to put init code. Only explicit uses of popcnt in the asm, with the CPU feature check around, going to end actually use the instruction in the generic code. And there, we may apply the workaround like I did for pmap. > > In regards to whether or not this should be a dynamic test instead, it seems a > bit much to require a dynamic check for code that has to work in both userland > and the kernel, and I'm not sure if something like CPU_COUNT() would actually > benefit from that versus just always using the software solution instead. I agree.