1. 04 Aug, 2016 1 commit
  2. 13 Jun, 2016 1 commit
  3. 19 Feb, 2016 1 commit
  4. 05 Aug, 2015 1 commit
  5. 17 Apr, 2015 1 commit
  6. 15 Apr, 2015 1 commit
    • Rasmus Villemoes's avatar
      linux/bitmap.h: improve BITMAP_{LAST,FIRST}_WORD_MASK · 89c1e79e
      Rasmus Villemoes authored
      The macro BITMAP_LAST_WORD_MASK can be implemented without a conditional,
      which will generally lead to slightly better generated code (221 bytes
      saved for allmodconfig-GCOV_KERNEL, ~2k with GCOV_KERNEL).  As a small
      bonus, this also ensures that the nbits parameter is expanded exactly
      once.
      
      In BITMAP_FIRST_WORD_MASK, if start is signed gcc is technically allowed
      to assume it is positive (or divisible by BITS_PER_LONG), and hence just
      do the simple mask.  It doesn't seem to use this, and even on an
      architecture like x86 where the shift only depends on the lower 5 or 6
      bits, and these bits are not affected by the signedness of the expression,
      gcc still generates code to compute the C99 mandated value of start %
      BITS_PER_LONG.  So just use a mask explicitly, also for consistency with
      BITMAP_LAST_WORD_MASK.
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Tejun Heo <tj@kernel.org>
      Reviewed-by: default avatarGeorge Spelvin <linux@horizon.com>
      Cc: Yury Norov <yury.norov@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      89c1e79e
  7. 13 Feb, 2015 5 commits
  8. 12 Feb, 2015 5 commits
  9. 13 Dec, 2014 1 commit
  10. 07 Nov, 2014 1 commit
  11. 06 Aug, 2014 15 commits
  12. 03 Aug, 2011 1 commit
    • Huang Ying's avatar
      lib, Make gen_pool memory allocator lockless · 7f184275
      Huang Ying authored
      This version of the gen_pool memory allocator supports lockless
      operation.
      
      This makes it safe to use in NMI handlers and other special
      unblockable contexts that could otherwise deadlock on locks.  This is
      implemented by using atomic operations and retries on any conflicts.
      The disadvantage is that there may be livelocks in extreme cases.  For
      better scalability, one gen_pool allocator can be used for each CPU.
      
      The lockless operation only works if there is enough memory available.
      If new memory is added to the pool a lock has to be still taken.  So
      any user relying on locklessness has to ensure that sufficient memory
      is preallocated.
      
      The basic atomic operation of this allocator is cmpxchg on long.  On
      architectures that don't have NMI-safe cmpxchg implementation, the
      allocator can NOT be used in NMI handler.  So code uses the allocator
      in NMI handler should depend on CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG.
      Signed-off-by: default avatarHuang Ying <ying.huang@intel.com>
      Reviewed-by: default avatarAndi Kleen <ak@linux.intel.com>
      Reviewed-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      7f184275
  13. 26 Jul, 2011 1 commit
    • Michal Hocko's avatar
      cpusets: randomize node rotor used in cpuset_mem_spread_node() · 778d3b0f
      Michal Hocko authored
      [ This patch has already been accepted as commit 0ac0c0d0 but later
        reverted (commit 35926ff5) because it itroduced arch specific
        __node_random which was defined only for x86 code so it broke other
        archs.  This is a followup without any arch specific code.  Other than
        that there are no functional changes.]
      
      Some workloads that create a large number of small files tend to assign
      too many pages to node 0 (multi-node systems).  Part of the reason is
      that the rotor (in cpuset_mem_spread_node()) used to assign nodes starts
      at node 0 for newly created tasks.
      
      This patch changes the rotor to be initialized to a random node number
      of the cpuset.
      
      [akpm@linux-foundation.org: fix layout]
      [Lee.Schermerhorn@hp.com: Define stub numa_random() for !NUMA configuration]
      [mhocko@suse.cz: Make it arch independent]
      [akpm@linux-foundation.org: fix CONFIG_NUMA=y, MAX_NUMNODES>1 build]
      Signed-off-by: default avatarJack Steiner <steiner@sgi.com>
      Signed-off-by: default avatarLee Schermerhorn <lee.schermerhorn@hp.com>
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.cz>
      Reviewed-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Paul Menage <menage@google.com>
      Cc: Jack Steiner <steiner@sgi.com>
      Cc: Robin Holt <holt@sgi.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Jack Steiner <steiner@sgi.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Paul Menage <menage@google.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Robin Holt <holt@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      778d3b0f
  14. 25 May, 2011 1 commit
    • Mike Travis's avatar
      bitmap, irq: add smp_affinity_list interface to /proc/irq · 4b060420
      Mike Travis authored
      Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
      cpu count is large.
      
      Setting smp affinity to cpus 256 to 263 would be:
      
      	echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
      
      instead of:
      
      	echo 256-263 > smp_affinity_list
      
      Think about what it looks like for cpus around say, 4088 to 4095.
      
      We already have many alternate "list" interfaces:
      
      /sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
      /sys/devices/system/cpu/cpuX/topology/thread_siblings_list
      /sys/devices/system/cpu/cpuX/topology/core_siblings_list
      /sys/devices/system/node/nodeX/cpulist
      /sys/devices/pci***/***/local_cpulist
      
      Add a companion interface, smp_affinity_list to use cpu lists instead of
      cpu maps.  This conforms to other companion interfaces where both a map
      and a list interface exists.
      
      This required adding a bitmap_parselist_user() function in a manner
      similar to the bitmap_parse_user() function.
      
      [akpm@linux-foundation.org: make __bitmap_parselist() static]
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jack Steiner <steiner@sgi.com>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4b060420
  15. 30 May, 2010 1 commit
  16. 27 May, 2010 1 commit
  17. 16 Dec, 2009 1 commit
    • Akinobu Mita's avatar
      bitmap: introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area · c1a2a962
      Akinobu Mita authored
      This introduces new bitmap functions:
      
      bitmap_set: Set specified bit area
      bitmap_clear: Clear specified bit area
      bitmap_find_next_zero_area: Find free bit area
      
      These are mostly stolen from iommu helper. The differences are:
      
      - Use find_next_bit instead of doing test_bit for each bit
      
      - Rewrite bitmap_set and bitmap_clear
      
        Instead of setting or clearing for each bit.
      
      - Check the last bit of the limit
      
        iommu-helper doesn't want to find such area
      
      - The return value if there is no zero area
      
        find_next_zero_area in iommu helper: returns -1
        bitmap_find_next_zero_area: return >= bitmap size
      Signed-off-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: Lothar Wassmann <LW@KARO-electronics.de>
      Cc: Roland Dreier <rolandd@cisco.com>
      Cc: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c1a2a962
  18. 21 Aug, 2009 1 commit
    • Linus Torvalds's avatar
      Make bitmask 'and' operators return a result code · f4b0373b
      Linus Torvalds authored
      When 'and'ing two bitmasks (where 'andnot' is a variation on it), some
      cases want to know whether the result is the empty set or not.  In
      particular, the TLB IPI sending code wants to do cpumask operations and
      determine if there are any CPU's left in the final set.
      
      So this just makes the bitmask (and cpumask) functions return a boolean
      for whether the result has any bits set.
      
      Cc: stable@kernel.org (2.6.30, needed by TLB shootdown fix)
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f4b0373b