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

[Attilio Rao]

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.

Attilio


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