From owner-svn-src-head@FreeBSD.ORG Sun May 8 10:14:36 2011 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A675106566B; Sun, 8 May 2011 10:14:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id E9C758FC13; Sun, 8 May 2011 10:14:35 +0000 (UTC) Received: from c122-106-155-58.carlnfd1.nsw.optusnet.com.au (c122-106-155-58.carlnfd1.nsw.optusnet.com.au [122.106.155.58]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p48AEQoA032357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 20:14:26 +1000 Date: Sun, 8 May 2011 20:14:25 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Hans Petter Selasky In-Reply-To: <201105071955.35305.hselasky@c2i.net> Message-ID: <20110508195020.V981@besplex.bde.org> References: <201105071628.p47GSO16006145@svn.freebsd.org> <201105071836.00660.hselasky@c2i.net> <201105071955.35305.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "svn-src-head@freebsd.org" , mdf@FreeBSD.org, "svn-src-all@freebsd.org" , "src-committers@freebsd.org" Subject: Re: svn commit: r221604 - head/usr.sbin/usbdump X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 08 May 2011 10:14:36 -0000 On Sat, 7 May 2011, Hans Petter Selasky wrote: > On Saturday 07 May 2011 19:13:27 mdf@freebsd.org wrote: >> On Sat, May 7, 2011 at 9:36 AM, Hans Petter Selasky > wrote: >>> On Saturday 07 May 2011 18:28:24 Hans Petter Selasky wrote: >>>> - Use memcpy() instead of bcopy(). >>> >>> - Use memset() instead of bzero(). >> >> Why? It usually falls through to the same code in libc. Is there >> some standardization on memfoo versus bfoo here? > > I thought that memset() was a compiler builtin and bzero() optimised for > larger amounts of data? In the kernel, compiler builtins aren't used, memset() is slightly pessimized, and bzero() is not optimized (except in old versions of FreeBSD on i386, attempts were made to optimize bzero() for large data at a tiny cost to small data). A better implementation would use the compiler builtin for both. My version does this, but the gains (or losses) from using builtins for this and other things in the kernel insignificant. Here it is for bzero(): #define bzero(p, n) ({ \ if (__builtin_constant_p(n) && (n) <= 32) \ __builtin_memset((p), 0, (n)); \ else \ (bzero)((p), (n)); \ }) This hard-codes the limit of 32 for the builtin since some versions of gcc use a worse limit. In userland, on at least amd64 and i386, the extern bzero() and memset() are unoptimized, but the compiler builtin is used for memset() only. A better implementation of bzero() would use the compiler builtin for it too. The above is not good enough for libc, since it evaluates args more than once and has a hard-coded gccism. The correct optimizations for bzero() etc. are very machine-dependent and context-dependent and are far too hard for anyone or the compiler or the CPU to get right (but I believe newer Intel CPUs are closer to making unoptimized stosb as fast as possible). Context-dependent parts include whether the data should go through cache(s) (it shouldn't iff it won't be used soon and the memory system is such that not going through caches is either faster or saves time later). Bruce