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

[Attilio Rao]

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.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein