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@xxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
