Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address

[Helge Deller <deller@gmx.de>]

On 22.02.2015 00:09, James Bottomley wrote:
> On Sat, 2015-02-21 at 15:40 -0500, John David Anglin wrote:
>> On 2015-02-21, at 3:31 PM, John David Anglin wrote:
>>
>>> On 2015-02-20, at 4:36 PM, Carlos O'Donell wrote:
>>>
>>>> On Thu, Apr 3, 2014 at 4:26 PM, Helge Deller <deller@gmx.de> wrote:
>>>>> In current eglibc it's set to 0x00400000
>>>>> That's what my eglibc-patch changes...
>>>>> I'm currently building a eglibc on hpviz with SHMLBA set to 4096 (__getpagesize()).
>>>>
>>>> Anyone object to me fixing this upstream by making SHMLBA match the kernel?
>>>>
>>>> I plan to use a fixed value of 4096, since I never expect hppa
>>>> userspace to have to care (even if the kernel uses superpages).
>>>
>>> We currently use (__getpagesize ()) in Debian and this seems to be a common definition.
>>> Is there a performance advantage in using 4096?
>>>
>>>>
>>>> Please correct me if I'm wrong.
>>>
>>>
>>> At one time, we thought this value needed to be 4 MB.  Helge was
>> working on improving the mmap
>>> allocation scheme but this work stalled after some improvement.  I
>> can't remember the issues and how
>>> they relate to SHMLBA.
>>
>>
>> Actually, the number was 4 Mb (bit).
>
> No, it was 4MB.  That's the cache equivalency stride on PA processors
> because we have a VIPT cache.  The architectural requirement according
> to the dreaded appendix F is 16MB but we were assured by the PA
> architects that it was 4 because they never planned producing processors
> that would require 16.  The actual meaning is it's the number of bits of
> the virtual address that are significant in the virtual index.
>

Your following statement:

> The point of SHMLBA is that if the same physical page is mapped into two
> different virtual addresses but the two addresses are equal, modulo
> SHMLBA, then the L1 cache sees the equivalency and you can't get
> inequivalent cache aliases for the page (two writes to the two different
> addresses producing two separately dirty cache lines which can never
> resolve).  This means that the virtual addresses of all shared mappings
> have to be equal modulo SHMLBA for the caches not to alias.

With this you define SHMLBA to be the representative number which defines
what the current cache equivalency stride of the kernel is, *and* which then can
be used by userspace. I think this is a misinterpretation of SHMLBA (or at
least a parisc-specific interpretation of SHMLBA), which is not like how it
is used on other architectures with similar limitations.
Userspace should not know the kernel/architecture specifics. Instead they
should try to mmap() memory somewhere (e.g. 4KB aligned) and if they need shared mappings then
kernel/glibc will return a corrected mapping address (modulo 4MB).
I think this is important, since most userspace programs usually try to mmap at
a multiple of SHMLBA with which we then run very soon out of userspace (with SHMLBA=4MB).
This has been the issue with localedef in glibc (a strange coding which tries
to be platform-specific with mmap-calculation). Because of that in the end
it turned out to be best for parisc to have SHMLBA defined to 4kb (and not 4MB).

So, your statement above is correct, I would just not use "SHMLBA" in this term,
but maybe "KERNEL_SHMLBA" instead.

Helge