From owner-freebsd-mips@FreeBSD.ORG Mon Nov 5 18:26:13 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 CE40E9AB for ; Mon, 5 Nov 2012 18:26:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7F3A88FC14 for ; Mon, 5 Nov 2012 18:26:13 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id k10so5883482iag.13 for ; Mon, 05 Nov 2012 10:26:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=fxtF5l0KaE+DF1uctTZtacGvbN/Llye35kZvl39NtvU=; b=KSuXFShfTI4L8uyf3pYp6JMoLAStUSMDzwGfkCS0M59O0YPzj3kgLIVtmWyx1XTpYw n7g66MnFMZOZjd+gPHANTnIZ7jjQU89cB5+7bEPDb551lDN9pzzsGue5YU98OpysY5u3 WApJXlEq466mo+dXoQfvWlJWKqh5ioxMLXmKpBlfFg90XCfeqgRT3/xaSbwwOiKvKW3u QjzrjU8kUnvJYrVm83JQghNBkuOiGLw+E02mcmzKZA7J4Gb1iXSKDK+/aaVyIQcXzf7v Uv9LGPylM5Nv3w3H0bBmHaF+IdGDTErI0JU2OhXReVjvdGmJLCRaRKDTQsSVoGgR92gU c0Fg== Received: by 10.50.17.170 with SMTP id p10mr5942122igd.5.1352139973063; Mon, 05 Nov 2012 10:26:13 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id eo7sm6724564igc.12.2012.11.05.10.26.10 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Nov 2012 10:26:11 -0800 (PST) Sender: Warner Losh Subject: Re: CACHE_LINE_SIZE macro. Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 5 Nov 2012 11:26:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201211041828.qA4ISomC076058@pdx.rh.CN85.ChatUSA.com> <1352137087.1120.180.camel@revolution.hippie.lan> <1352138944.1120.187.camel@revolution.hippie.lan> To: Eitan Adler X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmF88RvgYsdSqsMfoz/EL21Lr0WZwLpEriMckYAVRa/ssGhjEf6sRSFeuAnwryyK1vDk10O Cc: "Rodney W. Grimes" , 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: Mon, 05 Nov 2012 18:26:13 -0000 On Nov 5, 2012, at 11:12 AM, Eitan Adler wrote: > On 5 November 2012 13:09, Ian Lepore = wrote: >> The other thing that bugs me is that cache is a scarce resource on = our >> wimpy little platforms, and padding just ensures that we use it even >> less effectively in the UP case. It seems like it's more likely to = kill >> performance than improve it, because one would expect that when a = lock >> is embedded in a structure, there's going to be access to other data >> nearby once the lock is acquired. >=20 > This is another reason to encourage the separation between the real > cache line size and the lock padding version. On low cache-size > environments the latter could be tuned to not matter. Yea, we definitely need to separate out the difference between 'padding = for performance' which CACHE_LINE_SIZE does (and perhaps we need several = flavors), padding for correctness (which is needed for DMA correctness = wrt non-coherent cache architectures) and padding because padding always = helps, right? Warner