1. 10 Aug, 2017 37 commits
  2. 08 Aug, 2017 3 commits
    • Michael Ellerman's avatar
      powerpc/mm/hash64: Make vmalloc 56T on hash · 21a0e8c1
      Michael Ellerman authored
      On 64-bit book3s, with the hash MMU, we currently define the kernel
      virtual space (vmalloc, ioremap etc.), to be 16T in size. This is a
      leftover from pre v3.7 when our user VM was also 16T.
      
      Of that 16T we split it 50/50, with half used for PCI IO and ioremap
      and the other 8T for vmalloc.
      
      We never bothered to make it any bigger because 8T of vmalloc ought to
      be enough for anybody. But it turns out that's not true, the per cpu
      allocator wants large amounts of vmalloc space, not to make large
      allocations, but to allow a large stride between allocations, because
      we use pcpu_embed_first_chunk().
      
      With a bit of juggling we can increase the entire kernel virtual space
      to 64T. The only real complication is the check of the address in the
      SLB miss handler, see the comment in the code.
      
      Although we could continue to split virtual space 50/50 as we do now,
      no one seems to be running out of PCI IO or ioremap space. So instead
      keep that as 8T, and use the remaining 56T for vmalloc.
      
      In future we should be able to increase the kernel virtual space to
      512T, the code already supports that, it just needs testing on older
      hardware.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      21a0e8c1
    • Michael Ellerman's avatar
      powerpc/mm/slb: Move comment next to the code it's referring to · b5048de0
      Michael Ellerman authored
      There is a comment in slb_allocate() referring to the load of
      paca->vmalloc_sllp, but it's several lines prior in the assembly.
      We're about to change this code, and we want to add another comment,
      so move the comment immediately prior to the instruction it's talking
      about.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      b5048de0
    • Michael Ellerman's avatar
      powerpc/mm/book3s64: Make KERN_IO_START a variable · 63ee9b2f
      Michael Ellerman authored
      Currently KERN_IO_START is defined as:
      
       #define KERN_IO_START  (KERN_VIRT_START + (KERN_VIRT_SIZE >> 1))
      
      Although it looks like a constant, both the components are actually
      variables, to allow us to have a different value between Radix and
      Hash with a single kernel.
      
      However that still requires both Radix and Hash to place the kernel IO
      region at the same location relative to the start and end of the
      kernel virtual region (namely 1/2 way through it), and we'd like to
      change that.
      
      So split KERN_IO_START out into its own variable, and initialise it
      for Radix and Hash. In the medium term we should be able to
      reconsolidate this, by doing a more involved rearrangement of the
      location of the regions.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Acked-by: default avatarBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      63ee9b2f