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. 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. James -- 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
