From owner-cvs-all@FreeBSD.ORG Fri Sep 10 19:33:49 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3AE016A4CE; Fri, 10 Sep 2004 19:33:48 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id B07B543D49; Fri, 10 Sep 2004 19:33:48 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.13.1/8.13.1) with ESMTP id i8AJXm86010048; Fri, 10 Sep 2004 12:33:48 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.13.1/8.13.1/Submit) id i8AJXmKL010047; Fri, 10 Sep 2004 12:33:48 -0700 (PDT) (envelope-from marcel) Date: Fri, 10 Sep 2004 12:33:48 -0700 From: Marcel Moolenaar To: John Baldwin Message-ID: <20040910193348.GC9815@ns1.xcllnt.net> References: <200409100500.i8A50R7U038632@repoman.freebsd.org> <200409101506.53655.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409101506.53655.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/include atomic.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 19:33:49 -0000 On Fri, Sep 10, 2004 at 03:06:53PM -0400, John Baldwin wrote: > > Hmm, maybe leave it in but add 'MUTEX_NO_INLINE' to GENERIC on Alpha so that > GENERIC will build but people can take out the 'NO_INLINE' bit in custom > kernels if they want? I've thought about making it optional, but the bottomline is that the kluge-factor increases every time we need to add another workaround. Kluges require maintenance and that's where the problem is. And since this is only about performance, I'd rather remove micro-optimizations than disable normal compiler optimizations by way of kernel options. My PoV: anyone with an interest to actually work on it is in a position to preempt everything I do. I'm just trying to extend life and keeping bit of grace and quality if possible... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net