On 2015-02-22, at 12:17 PM, James Bottomley wrote: > On Sun, 2015-02-22 at 11:45 -0500, John David Anglin wrote: >> On 2015-02-21, at 6:57 PM, James Bottomley wrote: >> >>> On Sun, 2015-02-22 at 00:26 +0100, Helge Deller wrote: >>>> 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. >>> >>> Um, no, SHMLBA comes from the SYS-V IPC primitives. They were stupid >>> enough to allow the user pick the address of the region of shared >>> memory, so the user had to know these architectural details and SHMLBA >>> encodes them (man shmat will give you the gory details). >>> >>> For mmap, we can mostly do the right thing in the kernel, except for >>> MAP_FIXED, where the user has to know what they're doing again. >>> >>> For the cases the user thinks they know best, we can't avoid giving out >>> the knowledge somehow, because inequivalent aliases in writeable >>> mappings will HPMC a system. We could be more relaxed about >>> inequivalent aliases in read only mappings (say shared libraries), but >>> the consequence of that is an explosion in the use of cache space, so we >>> would want some libraries (like glibc) with many shared copies to obey >>> SHMLBA. >> >> >> I agree with Helge. We run out of memory too quickly with 4 MB. This resulted in various >> userspace applications failing as mentioned by Helge. >> >> MAP_FIXED can fail it the address is a problem. I believe we check for that. >> >> If you look at the pch implementation in gcc, you will see that the MAP_FIXED problem can be >> worked around, and this problem is not specific to parisc. The pch data has to mapped at the same >> address as it was originally created as there is no way to relocate the data. >> >> SHMLBA is 4096 /* (1 << PGSHIFT) */ on hpux. >> >> The following is in <asm-generic/shmparam.h>: >> #define SHMLBA PAGE_SIZE /* attach addr a multiple of this */ >> >> Shared mappings are handled with >> asm/shmparam.h:#define SHM_COLOUR 0x00400000 /* shared mappings colouring */ > > So how is the sys-v ipc problem fixed? There the user is told to select > an address which is a multiple of SHMLBA. Programs that do this today > will start to break on writeable mappings if we set SHMLBA to PAGE_SIZE > because the colour will be wrong. The code returns -EINVAL. See arch_get_unmapped_area. Dave -- John David Anglin dave.anglin@xxxxxxxx -- 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
