From owner-freebsd-mips@FreeBSD.ORG Tue Nov 6 21:42:30 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DAF5341E for ; Tue, 6 Nov 2012 21:42:30 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.ChatUSA.com) Received: from pdx.rh.CN85.ChatUSA.com (pdx.rh.CN85.ip6.chatusa.com [IPv6:2607:fa80:104::6]) by mx1.freebsd.org (Postfix) with ESMTP id 7401A8FC0A for ; Tue, 6 Nov 2012 21:42:30 +0000 (UTC) Received: from pdx.rh.CN85.ChatUSA.com (localhost [127.0.0.1]) by pdx.rh.CN85.ChatUSA.com (8.13.3/8.13.3) with ESMTP id qA5CAjT0094797; Mon, 5 Nov 2012 04:10:45 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.ChatUSA.com) Received: (from freebsd@localhost) by pdx.rh.CN85.ChatUSA.com (8.13.3/8.13.3/Submit) id qA5CAiLx094796; Mon, 5 Nov 2012 04:10:44 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201211051210.qA5CAiLx094796@pdx.rh.CN85.ChatUSA.com> Subject: Re: CACHE_LINE_SIZE macro. In-Reply-To: <1352137087.1120.180.camel@revolution.hippie.lan> To: Ian Lepore Date: Mon, 5 Nov 2012 04:10:44 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: Juli Mallett , "freebsd-mips@FreeBSD.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 21:42:30 -0000 > > > > this is a kernel-only interface, so compile time constants are fine there. What user-land visible interfaces are affected by this setting? The answer should be 'none' > > > > Warner > > When I commented on Attilio's recent checkins concerning padding of > locks to cache line size and the fact that the value changes per-cpu and > we're not well-positioned to handle that right now, his main concern was > modules matching the kernel. I had suggested making the padding > conditional on SMP (because apparently there's no benefit to the padding > in a UP kernel), but then a module compiled for UP wouldn't work right > on an SMP kernel, and vice versa. I'm not sure why that's a problem, my > solution to that would be "So then don't do that." > > What scares me the most is the mushy definition of what CACHE_LINE_SIZE > really means. There's nothing about the name that says "This may not be > the actual cache line size but it's probably close," but increasingly I > see people talking about it as if it had such a malleable meaning. Is > that consistant with the existing uses in the code? Is it a good idea? I agree with your point Ian, one should not be abusing a constant that just happens to fit the value needs, one should be using a new constant such as MUTEX_ALIGN. Interesting things can be found if one runs a find /sys/ -type f | xarges grep ALIGN Like this pair of contradictions: ./dev/fxp/if_fxpvar.h:#define FXP_FLAG_READ_ALIGN 0x0002 /* align read access with cacheline */ ./dev/fxp/if_fxpvar.h:#define FXP_FLAG_WRITE_ALIGN 0x0004 /* end write on cacheline */ Both often wrong, cause the cache line size on most x86 is much larger than 2 or 4 :-) -- Rod Grimes freebsd@freebsd.org