svn commit: r242402 - in head/sys: kern vm

Ian Lepore freebsd at damnhippie.dyndns.org
Thu Nov 1 14:37:18 UTC 2012


On Thu, 2012-11-01 at 14:07 +0000, Attilio Rao wrote:
> On Thu, Nov 1, 2012 at 2:05 PM, Attilio Rao <attilio at freebsd.org> wrote:
> > On Thu, Nov 1, 2012 at 2:01 PM, Ian Lepore
> > <freebsd at damnhippie.dyndns.org> wrote:
> >> On Thu, 2012-11-01 at 10:42 +0000, Attilio Rao wrote:
> >>> On 11/1/12, Gleb Smirnoff <glebius at freebsd.org> 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.

Back from some quick googling... yep, arm cortex-a8 processors have a
64-byte cache line size.  Maybe we don't support those yet, which is why
the value appears to be constant in arm param.h right now.

-- Ian




More information about the svn-src-all mailing list