1. 30 8月, 2014 1 次提交
  2. 07 8月, 2014 3 次提交
  3. 05 6月, 2014 2 次提交
  4. 20 3月, 2014 1 次提交
    • S
      zsmalloc: Fix CPU hotplug callback registration · f0e71fcd
      Srivatsa S. Bhat 提交于
      Subsystems that want to register CPU hotplug callbacks, as well as perform
      initialization for the CPUs that are already online, often do it as shown
      below:
      
      	get_online_cpus();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	register_cpu_notifier(&foobar_cpu_notifier);
      
      	put_online_cpus();
      
      This is wrong, since it is prone to ABBA deadlocks involving the
      cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
      with CPU hotplug operations).
      
      Instead, the correct and race-free way of performing the callback
      registration is:
      
      	cpu_notifier_register_begin();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	/* Note the use of the double underscored version of the API */
      	__register_cpu_notifier(&foobar_cpu_notifier);
      
      	cpu_notifier_register_done();
      
      Fix the zsmalloc code by using this latter form of callback registration.
      
      Cc: Nitin Gupta <ngupta@vflare.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Acked-by: NMinchan Kim <minchan@kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f0e71fcd
  5. 31 1月, 2014 2 次提交
    • M
      zsmalloc: add copyright · 31fc00bb
      Minchan Kim 提交于
      Add my copyright to the zsmalloc source code which I maintain.
      Signed-off-by: NMinchan Kim <minchan@kernel.org>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      31fc00bb
    • M
      zsmalloc: move it under mm · bcf1647d
      Minchan Kim 提交于
      This patch moves zsmalloc under mm directory.
      
      Before that, description will explain why we have needed custom
      allocator.
      
      Zsmalloc is a new slab-based memory allocator for storing compressed
      pages.  It is designed for low fragmentation and high allocation success
      rate on large object, but <= PAGE_SIZE allocations.
      
      zsmalloc differs from the kernel slab allocator in two primary ways to
      achieve these design goals.
      
      zsmalloc never requires high order page allocations to back slabs, or
      "size classes" in zsmalloc terms.  Instead it allows multiple
      single-order pages to be stitched together into a "zspage" which backs
      the slab.  This allows for higher allocation success rate under memory
      pressure.
      
      Also, zsmalloc allows objects to span page boundaries within the zspage.
      This allows for lower fragmentation than could be had with the kernel
      slab allocator for objects between PAGE_SIZE/2 and PAGE_SIZE.  With the
      kernel slab allocator, if a page compresses to 60% of it original size,
      the memory savings gained through compression is lost in fragmentation
      because another object of the same size can't be stored in the leftover
      space.
      
      This ability to span pages results in zsmalloc allocations not being
      directly addressable by the user.  The user is given an
      non-dereferencable handle in response to an allocation request.  That
      handle must be mapped, using zs_map_object(), which returns a pointer to
      the mapped region that can be used.  The mapping is necessary since the
      object data may reside in two different noncontigious pages.
      
      The zsmalloc fulfills the allocation needs for zram perfectly
      
      [sjenning@linux.vnet.ibm.com: borrow Seth's quote]
      Signed-off-by: NMinchan Kim <minchan@kernel.org>
      Acked-by: NNitin Gupta <ngupta@vflare.org>
      Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Bob Liu <bob.liu@oracle.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Luigi Semenzato <semenzato@google.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bcf1647d
  6. 18 12月, 2013 1 次提交
  7. 11 12月, 2013 2 次提交
  8. 26 11月, 2013 1 次提交
    • O
      staging: zsmalloc: Ensure handle is never 0 on success · 67296874
      Olav Haugan 提交于
      zsmalloc encodes a handle using the pfn and an object
      index. On hardware platforms with physical memory starting
      at 0x0 the pfn can be 0. This causes the encoded handle to be
      0 and is incorrectly interpreted as an allocation failure.
      
      This issue affects all current and future SoCs with physical
      memory starting at 0x0. All MSM8974 SoCs which includes
      Google Nexus 5 devices are affected.
      
      To prevent this false error we ensure that the encoded handle
      will not be 0 when allocation succeeds.
      Signed-off-by: NOlav Haugan <ohaugan@codeaurora.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67296874
  9. 24 7月, 2013 1 次提交
  10. 22 5月, 2013 1 次提交
  11. 21 5月, 2013 1 次提交
  12. 24 4月, 2013 1 次提交
    • A
      staging/zsmalloc: don't use pgtable-mapping from modules · 796ce5a7
      Arnd Bergmann 提交于
      Building zsmalloc as a module does not work on ARM because it uses
      an interface that is not exported:
      
      ERROR: "flush_tlb_kernel_range" [drivers/staging/zsmalloc/zsmalloc.ko] undefined!
      
      Since this is only used as a performance optimization and only on ARM,
      we can avoid the problem simply by not using that optimization when
      building zsmalloc it is a loadable module.
      
      flush_tlb_kernel_range is often an inline function, but out of the
      architectures that use an extern function, only powerpc exports
      it.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      796ce5a7
  13. 29 3月, 2013 1 次提交
  14. 24 2月, 2013 1 次提交
  15. 31 1月, 2013 1 次提交
  16. 30 1月, 2013 2 次提交
    • M
      staging: zsmalloc: Fix TLB coherency and build problem · 99155188
      Minchan Kim 提交于
      Recently, Matt Sealey reported he fail to build zsmalloc caused by
      using of local_flush_tlb_kernel_range which are architecture dependent
      function so !CONFIG_SMP in ARM couldn't implement it so it ends up
      build error following as.
      
        MODPOST 216 modules
        LZMA    arch/arm/boot/compressed/piggy.lzma
        AS      arch/arm/boot/compressed/lib1funcs.o
      ERROR: "v7wbi_flush_kern_tlb_range"
      [drivers/staging/zsmalloc/zsmalloc.ko] undefined!
      make[1]: *** [__modpost] Error 1
      make: *** [modules] Error 2
      make: *** Waiting for unfinished jobs....
      
      The reason we used that function is copy method by [1]
      was really slow in ARM but at that time.
      
      More severe problem is ARM can prefetch speculatively on other CPUs
      so under us, other TLBs can have an entry only if we do flush local
      CPU. Russell King pointed that. Thanks!
      We don't have many choices except using flush_tlb_kernel_range.
      
      My experiment in ARMv7 processor 4 core didn't make any difference with
      zsmapbench[2] between local_flush_tlb_kernel_range and flush_tlb_kernel_range
      but still page-table based is much better than copy-based.
      
      * bigger is better.
      
      1. local_flush_tlb_kernel_range: 3918795 mappings
      2. flush_tlb_kernel_range : 3989538 mappings
      3. copy-based: 635158 mappings
      
      This patch replace local_flush_tlb_kernel_range with
      flush_tlb_kernel_range which are avaialbe in all architectures
      because we already have used it in vmalloc allocator which are
      generic one so build problem should go away and performane loss
      shoud be void.
      
      [1] f553646a, zsmalloc: add page table mapping method
      [2] https://github.com/spartacus06/zsmapbench
      
      Cc: stable@vger.kernel.org
      Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>
      Reported-by: NMatt Sealey <matt@genesi-usa.com>
      Signed-off-by: NMinchan Kim <minchan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      99155188
    • S
      staging: zsmalloc: make CLASS_DELTA relative to PAGE_SIZE · d662b8eb
      Seth Jennings 提交于
      Right now ZS_SIZE_CLASS_DELTA is hardcoded to be 16.  This
      creates 254 classes for systems with 4k pages. However, on
      PPC64 with 64k pages, it creates 4095 classes which is far
      too many.
      
      This patch makes ZS_SIZE_CLASS_DELTA relative to PAGE_SIZE
      so that regardless of the page size, there will be the same
      number of classes.
      Acked-by: NNitin Gupta <ngupta@vflare.org>
      Acked-by: NMinchan Kim <minchan@kernel.org>
      Signed-off-by: NSeth Jennings <sjenning@linux.vnet.ibm.com>
      Acked-by: NDan Magenheimer <dan.magenheimer@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d662b8eb
  17. 16 1月, 2013 1 次提交
  18. 14 8月, 2012 4 次提交
  19. 10 7月, 2012 4 次提交
  20. 21 6月, 2012 1 次提交
  21. 14 6月, 2012 1 次提交
  22. 12 6月, 2012 1 次提交
  23. 11 6月, 2012 1 次提交
  24. 10 5月, 2012 2 次提交
  25. 26 4月, 2012 1 次提交
  26. 11 4月, 2012 1 次提交
  27. 08 3月, 2012 1 次提交