From owner-svn-src-all@FreeBSD.ORG Mon Mar 30 16:40:20 2015 Return-Path: Delivered-To: svn-src-all@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 9FA2FD16; Mon, 30 Mar 2015 16:40:20 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 77183D0D; Mon, 30 Mar 2015 16:40:20 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 75B99B96C; Mon, 30 Mar 2015 12:40:19 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: svn commit: r280279 - head/sys/sys Date: Mon, 30 Mar 2015 11:57:08 -0400 Message-ID: <2526359.g5B2nXdKeQ@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20150322093251.GY2379@kib.kiev.ua> References: <201503201027.t2KAR6Ze053047@svn.freebsd.org> <20150322080015.O955@besplex.bde.org> <20150322093251.GY2379@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 30 Mar 2015 12:40:19 -0400 (EDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 16:40:20 -0000 On Sunday, March 22, 2015 11:32:51 AM Konstantin Belousov wrote: > On Sun, Mar 22, 2015 at 09:41:53AM +1100, Bruce Evans wrote: > > Always using new API would lose the micro-optimizations given by the runtime > > decision for default CFLAGS (used by distributions for portability). To > > keep them, it seems best to keep the inline asm but replace > > popcnt_pc_map_elem(elem) by __bitcount64(elem). -mno-popcount can then > > be used to work around slowness in the software (that is actually > > hardware) case. > > So anybody has to compile his own kernel to get popcnt optimization ? > We do care about trivial things that improve time. That is not what Bruce said. He suggested using bitcount64() for the fallback if the cpuid check fails. He did not say to remove the runtime check to use popcnt if it is available: "Always using [bitcount64] would lose the micro-optimization... [to] keep [it], it seems best to keep the inline asm but replace popcnt_pc_map_elem(elem) by [bitcount64(elem)]." > BTW, I have the following WIP change, which popcnt xorl is a piece of. > It emulates the ifuncs with some preprocessing mess. It is much better > than runtime patching, and is a prerequisite to properly support more > things, like SMAP. I did not published it earlier, since I wanted to > convert TLB flush code to this. This looks fine to me. It seems to be manually converting certain symbols to use a dynamic lookup that must be explicitly resolved before first use? I agree that this seems cleaner than runtime patching. -- John Baldwin