From owner-freebsd-mips@FreeBSD.ORG Mon Nov 5 17:49:45 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 EFBBC82E for ; Mon, 5 Nov 2012 17:49:45 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 94F768FC12 for ; Mon, 5 Nov 2012 17:49:45 +0000 (UTC) Received: by mail-gh0-f182.google.com with SMTP id r20so1124075ghr.13 for ; Mon, 05 Nov 2012 09:49:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=OJ6CyPOiL0hgmvQgVa+/v5BcSK+GV4jEB/PoIjRsv2c=; b=A344NvM9AHBUKZmpP3kOjdHdqfRnjAxcV8QNRel7VfVGYg+ggGLthsTFksFzTlsKkT L9Zqg+AjoogBLzgMRmHtku7pYIyabAMWlDQW94Q4s0rfhxkThjpg5L/K0yPnyga4wN1y m8cYni6QdnWE3dFY1wyPUnLVatymaPzM2DvwXqkF855VKTk1OfCwWzaAHNFmyj9uulY/ O1/vTejBG3X04xVGoj25hSv7dUgacLgFL5xm8NTGm3IgKsWOXFYaq8Nx9UizunICFiYB Ut3OXIbuG7eg7QUL5ZYiLGUe4ZEhAE/FQQGvLfk6VAf6Zk/He6h50PoOCkvxJDns7bE/ NK0w== Received: by 10.236.131.138 with SMTP id m10mr9731481yhi.101.1352137784872; Mon, 05 Nov 2012 09:49:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.146.227.39 with HTTP; Mon, 5 Nov 2012 09:49:24 -0800 (PST) In-Reply-To: <1352137087.1120.180.camel@revolution.hippie.lan> References: <201211041828.qA4ISomC076058@pdx.rh.CN85.ChatUSA.com> <1352137087.1120.180.camel@revolution.hippie.lan> From: Juli Mallett Date: Mon, 5 Nov 2012 09:49:24 -0800 Message-ID: Subject: Re: CACHE_LINE_SIZE macro. To: Ian Lepore X-Gm-Message-State: ALoCoQl2zv8pVr1bJhtVFsKy0V+TcLCPEQNvwR13Z5gONrYjd6EHvyWdHGAd6kkAJ2DrEWIo4mtF Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Rodney W. Grimes" , "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: Mon, 05 Nov 2012 17:49:46 -0000 On Mon, Nov 5, 2012 at 9:38 AM, Ian Lepore wrote: > 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? Agreed. If the point of the macro is to ensure that something aligned and padded to that size will never, ever share a cache line, and if it affects module builds, it seems like the only really safe thing would be just to align to page size, and enough of all this more conservative, namely too-conservative, stuff. And it shouldn't be named such that anyone tries to make it even remotely related to anything that may vary within an architecture. I had thought there were user/kernel interfaces where it might start to matter, but if not then the module/kernel interfaces are the worst of it, but still bad enough. (Although there are other things complicating things on MIPS based on CPU type, it would be nice to find ways to reduce those things, rather than increasing them.)