From owner-svn-src-all@FreeBSD.ORG Sat Nov 22 22:05:34 2008 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 032B91065673; Sat, 22 Nov 2008 22:05:34 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id DD9BD8FC19; Sat, 22 Nov 2008 22:05:32 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id mAMM5Mfh020749; Sat, 22 Nov 2008 15:05:23 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <49288222.5060205@samsco.org> Date: Sat, 22 Nov 2008 15:05:22 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: kmacy@FreeBSD.org References: <200811220555.mAM5tuIJ007781@svn.freebsd.org> <20081122112949.GA6408@deviant.kiev.zoral.com.ua> <3c1674c90811221326m41e229f7p6abbc0eb473e900e@mail.gmail.com> In-Reply-To: <3c1674c90811221326m41e229f7p6abbc0eb473e900e@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Kostik Belousov , svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r185162 - in head: . sys/amd64/include sys/arm/include sys/conf sys/dev/bce sys/dev/cxgb sys/dev/cxgb/sys sys/dev/cxgb/ulp/iw_cxgb sys/dev/mxge sys/dev/nxge sys/i386/include sys/i386/in... X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 22 Nov 2008 22:05:34 -0000 A neat hack would be for the kernel linker to scan the text and do a drop-in replacement of the opcode that is appropriate for the platform. I can't see how a CPU_XXX definition would work because it's just a compile time construct, one that can be included with any kernel compile. Scott kmacy@FreeBSD.org wrote: > This was a concern of mine - note that many driver writers assume they exist. > > Thoughts on efficiently handling it via checking cpuid at runtime? > Alternatively we could have it be conditional on CPU_i786. > > On 11/22/08, Kostik Belousov wrote: >> On Sat, Nov 22, 2008 at 05:55:56AM +0000, Kip Macy wrote: >>> Author: kmacy >>> Date: Sat Nov 22 05:55:56 2008 >>> New Revision: 185162 >>> URL: http://svn.freebsd.org/changeset/base/185162 >>> >>> Log: >>> - bump __FreeBSD version to reflect added buf_ring, memory barriers, >>> and ifnet functions >>> >>> - add memory barriers to >>> Modified: head/sys/i386/include/atomic.h >>> ============================================================================== >>> --- head/sys/i386/include/atomic.h Sat Nov 22 01:48:20 2008 (r185161) >>> +++ head/sys/i386/include/atomic.h Sat Nov 22 05:55:56 2008 (r185162) >>> @@ -32,6 +32,21 @@ >>> #error this file needs sys/cdefs.h as a prerequisite >>> #endif >>> >>> + >>> +#if defined(I686_CPU) >>> +#define mb() __asm__ __volatile__ ("mfence;": : :"memory") >>> +#define wmb() __asm__ __volatile__ ("sfence;": : :"memory") >>> +#define rmb() __asm__ __volatile__ ("lfence;": : :"memory") >>> +#else >>> +/* >>> + * do we need a serializing instruction? >>> + */ >>> +#define mb() >>> +#define wmb() >>> +#define rmb() >>> +#endif >>> + >>> + >>> /* >>> * Various simple operations on memory, each of which is atomic in the >>> * presence of interrupts and multiple processors. >> AFAIR, sfence instruction was added with the Pentium III processor (SSE), >> while lfence was introduced with the Pentium 4 (SSE2). >> >> I think that #ifdef I686_CPU handling of the fences is wrong. We need to >> use a serialized instruction on CPUs that does not support corresponding >> fence, if needed. >> > >