From owner-svn-src-head@FreeBSD.ORG Sat Nov 22 22:10:52 2008 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 3597D1065677 for ; Sat, 22 Nov 2008 22:10:52 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id 1CC818FC1E for ; Sat, 22 Nov 2008 22:10:52 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1452505rvf.43 for ; Sat, 22 Nov 2008 14:10:51 -0800 (PST) Received: by 10.140.192.9 with SMTP id p9mr1033027rvf.57.1227391851741; Sat, 22 Nov 2008 14:10:51 -0800 (PST) Received: by 10.141.153.21 with HTTP; Sat, 22 Nov 2008 14:10:51 -0800 (PST) Message-ID: <3c1674c90811221410m4cadf277x9aa6f1fd4bfc2848@mail.gmail.com> Date: Sat, 22 Nov 2008 22:10:51 +0000 From: kmacy@freebsd.org To: "Scott Long" In-Reply-To: <49288222.5060205@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811220555.mAM5tuIJ007781@svn.freebsd.org> <20081122112949.GA6408@deviant.kiev.zoral.com.ua> <3c1674c90811221326m41e229f7p6abbc0eb473e900e@mail.gmail.com> <49288222.5060205@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-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: Sat, 22 Nov 2008 22:10:52 -0000 On 11/22/08, Scott Long wrote: > 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. Yup, Linux does that for a number of things wasn't sure we want to go down that road. > 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. It would be the user's responsibility not to include it if his target platform doesn't support it. > 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. >>> >> >> > > -- If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis