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

[Ian Lepore]

On Thu, 2012-11-01 at 14:43 +0000, Attilio Rao wrote:
> On 11/1/12, Ian Lepore <freebsd at damnhippie.dyndns.org> wrote:
> > 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.
> 
> 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.
> 

I do a lot of work with armv4 and recently v5 chips, but nothing with
the v6/v7 stuff yet, so I'm not really an expert on these issues either.
I've heard some talk from the folks working on arm v6/v7 support about
things like unified kernels and an arm GENERIC kernel config, but I'm
pretty hazy myself on how that vision is shaping up.

-- Ian