From owner-svn-src-all@FreeBSD.ORG Thu Nov 1 14:43:24 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 120148A6; Thu, 1 Nov 2012 14:43:24 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id C99D28FC0A; Thu, 1 Nov 2012 14:43:22 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so2403124lbd.13 for ; Thu, 01 Nov 2012 07:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8L77GiuJ7oB8jSdZepK0e1DEz1pBJQaH1etANJxkxfY=; b=BQ0l0LtXtTSc4V4sL/lVeZj41rgzIXRNdXzkwTy4mP8zpwe/91NUu4bOqg/Tn8MznW DRm56P9C54gTZBOxh1i6Wrux768sQLX4fm2fyv9OMQgGPvy6GTUnUUCA7NSe0LGpscbp gS7Ed5ySc0Arwy6hH66sSM3D8wHWqUuPHTq9QEkSiy1eazo3JJwx/iOfSDHhEtlpF2dB 0XCkQ1VJbX1zA08LFwUdlPdsXwPUEjj5Y5i193XV+tXBWIhUa4WKy4emmCXJqc+kaiov 9ekuNFvPyidqdZ8WYqmZNKidYNQ2TZEi4y7TmjqJCLsms3WlobrdIU1ba2XYn17UvLZT 3Sfg== MIME-Version: 1.0 Received: by 10.112.82.103 with SMTP id h7mr15977545lby.50.1351781001319; Thu, 01 Nov 2012 07:43:21 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Thu, 1 Nov 2012 07:43:21 -0700 (PDT) In-Reply-To: <1351780635.1120.135.camel@revolution.hippie.lan> References: <201210311807.q9VI7IcX000993@svn.freebsd.org> <1351707964.1120.97.camel@revolution.hippie.lan> <20121101100814.GB70741@FreeBSD.org> <1351778472.1120.117.camel@revolution.hippie.lan> <1351780635.1120.135.camel@revolution.hippie.lan> Date: Thu, 1 Nov 2012 14:43:21 +0000 X-Google-Sender-Auth: U2LAWiSGNQxXDkUCTD8JQAoZVfY Message-ID: Subject: Re: svn commit: r242402 - in head/sys: kern vm From: Attilio Rao To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Gleb Smirnoff , src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:43:24 -0000 On 11/1/12, Ian Lepore wrote: > On Thu, 2012-11-01 at 14:07 +0000, Attilio Rao wrote: >> On Thu, Nov 1, 2012 at 2:05 PM, Attilio Rao wrote: >> > On Thu, Nov 1, 2012 at 2:01 PM, Ian Lepore >> > wrote: >> >> On Thu, 2012-11-01 at 10:42 +0000, Attilio Rao wrote: >> >>> On 11/1/12, Gleb Smirnoff wrote: >> >>> > On Wed, Oct 31, 2012 at 06:33:51PM +0000, Attilio Rao wrote: >> >>> > A> > Doesn't this padding to cache line size only help x86 >> >>> > processors in an >> >>> > A> > SMP kernel? I was expecting to see some #ifdef SMP so that we >> >>> > don't >> >>> > pay >> >>> > A> > a big price for no gain in small-memory ARM systems and such. >> >>> > But >> >>> > maybe >> >>> > A> > I'm misunderstanding the reason for the padding. >> >>> > A> >> >>> > A> I didn't want to do this because this would be meaning that SMP >> >>> > option >> >>> > A> may become a completely killer for modules/kernel ABI >> >>> > compatibility. >> >>> > >> >>> > Do we support loading non-SMP modules on SMP kernel and vice versa? >> >>> >> >>> Actually that's my point, we do. >> >>> >> >>> Attilio >> >>> >> >>> >> >> >> >> Well we've got other similar problems lurking then. What about a >> >> module >> >> compiled on an arm system that had #define CACHE_LINE_SIZE 32 and then >> >> it gets run on a different arm system whose kernel is compiled with >> >> #define CACHE_LINE_SIZE 64? >> > >> > That should not happen. Is that a real case where you build a module >> > for an ARM family and want to run against a kernel compiled for >> > another? >> >> Besides that, the ARM CACHE_LINE_SIZE is defined in the shared headers >> so there is no way this can be a problem. > > I've been under the impression that in the ARM and MIPS worlds, the > cache line size can change from one family/series of chips to another, > just as support for SMP can change from one family to another. If I'm > not mistaken in that assumption, then there can't be something like a > generic arm module that will run on any arm kernel regardless of how the > kernel was built, not if compile-time constants get cooked into the > binaries in a way that affects the ABI/KBI. I'm far from being an ARM expert so I trust what you say. This only means you cannot build a module for a family and expect to retain ABI compatibility among all the ARM families. If cache-lines are different I don't think there is much we can do, which has nothing to do with pad-align locking. Attilio -- Peace can only be achieved by understanding - A. Einstein