1. 09 Sep, 2014 1 commit
  2. 06 Dec, 2012 1 commit
  3. 29 May, 2012 1 commit
  4. 07 Mar, 2012 1 commit
  5. 29 Feb, 2012 1 commit
  6. 01 Nov, 2011 1 commit
    • H Hartley Sweeten's avatar
      lib/bitmap.c: quiet sparse noise about address space · b9c321fd
      H Hartley Sweeten authored
      
      
      __bitmap_parse() and __bitmap_parselist() both take a pointer to a kernel
      buffer as a parameter and then cast it to a pointer to user buffer for use
      in cases when the parameter is_user indicates that the buffer is actually
      located in user space.  This casting, and the casts in the callers,
      results in sparse noise like the following:
      
      	warning: incorrect type in initializer (different address spaces)
      	  expected char const [noderef] <asn:1>*ubuf
      	  got char const *buf
      	warning: cast removes address space of expression
      
      Since these casts are intentional, use __force to quiet the noise.
      Signed-off-by: default avatarH Hartley Sweeten <hsweeten@visionengravers.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b9c321fd
  7. 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
  8. 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: Lee ...
      778d3b0f
  9. 16 Jun, 2011 1 commit
  10. 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
  11. 31 Mar, 2011 1 commit
  12. 26 Oct, 2010 1 commit
  13. 30 May, 2010 1 commit
  14. 27 May, 2010 1 commit
  15. 06 Mar, 2010 2 commits
  16. 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
  17. 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
  18. 13 Mar, 2009 1 commit
  19. 20 Oct, 2008 1 commit
  20. 17 Sep, 2008 1 commit
    • David Vrabel's avatar
      bitmap: add bitmap_copy_le() · ccbe329b
      David Vrabel authored
      
      
      bitmap_copy_le() copies a bitmap, putting the bits into little-endian
      order (i.e., each unsigned long word in the bitmap is put into
      little-endian order).
      
      The UWB stack used bitmaps to manage Medium Access Slot availability,
      and these bitmaps need to be written to the hardware in LE order.
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@csr.com>
      ccbe329b
  21. 12 Aug, 2008 1 commit
  22. 13 May, 2008 1 commit
  23. 28 Apr, 2008 1 commit
    • Paul Jackson's avatar
      mempolicy: add bitmap_onto() and bitmap_fold() operations · 7ea931c9
      Paul Jackson authored
      
      
      The following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),
      with the usual cpumask and nodemask wrappers.
      
      The bitmap_onto() operator computes one bitmap relative to another.  If the
      n-th bit in the origin mask is set, then the m-th bit of the destination mask
      will be set, where m is the position of the n-th set bit in the relative mask.
      
      The bitmap_fold() operator folds a bitmap into a second that has bit m set iff
      the input bitmap has some bit n set, where m == n mod sz, for the specified sz
      value.
      
      There are two substantive changes between this patch and its
      predecessor bitmap_relative:
       1) Renamed bitmap_relative() to be bitmap_onto().
       2) Added bitmap_fold().
      
      The essential motivation for bitmap_onto() is to provide a mechanism for
      converting a cpuset-relative CPU or Node mask to an absolute mask.  Cpuset
      relative masks are written as if the current task were in a cpuset whose CPUs
      or Nodes were just the consecutive ones numbered 0..N-1, for some N.  The
      bitmap_onto() operator is provided in anticipation of adding support for the
      first such cpuset relative mask, by the mbind() and set_mempolicy() system
      calls, using a planned flag of MPOL_F_RELATIVE_NODES.  These bitmap operators
      (and their nodemask wrappers, in particular) will be used in code that
      converts the user specified cpuset relative memory policy to a specific system
      node numbered policy, given the current mems_allowed of the tasks cpuset.
      
      Such cpuset relative mempolicies will address two deficiencies
      of the existing interface between cpusets and mempolicies:
       1) A task cannot at present reliably establish a cpuset
          relative mempolicy because there is an essential race
          condition, in that the tasks cpuset may be changed in
          between the time the task can query its cpuset placement,
          and the time the task can issue the applicable mbind or
          set_memplicy system call.
       2) A task cannot at present establish what cpuset relative
          mempolicy it would like to have, if it is in a smaller
          cpuset than it might have mempolicy preferences for,
          because the existing interface only allows specifying
          mempolicies for nodes currently allowed by the cpuset.
      
      Cpuset relative mempolicies are useful for tasks that don't distinguish
      particularly between one CPU or Node and another, but only between how many of
      each are allowed, and the proper placement of threads and memory pages on the
      various CPUs and Nodes available.
      
      The motivation for the added bitmap_fold() can be seen in the following
      example.
      
      Let's say an application has specified some mempolicies that presume 16 memory
      nodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset
      relative) nodes 12-15.  Then lets say that application is crammed into a
      cpuset that only has 8 memory nodes, 0-7.  If one just uses bitmap_onto(),
      this mempolicy, mapped to that cpuset, would ignore the requested relative
      nodes above 7, leaving it empty of nodes.  That's not good; better to fold the
      higher nodes down, so that some nodes are included in the resulting mapped
      mempolicy.  In this case, the mempolicy nodes 12-15 are taken modulo 8 (the
      weight of the mems_allowed of the confining cpuset), resulting in a mempolicy
      specifying nodes 4-7.
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Christoph Lameter <clameter@sgi.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: <kosaki.motohiro@jp.fujitsu.com>
      Cc: <ray-lk@madrabbit.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7ea931c9
  24. 19 Apr, 2008 1 commit
    • Mike Travis's avatar
      cpumask: add cpumask_scnprintf_len function · 30ca60c1
      Mike Travis authored
      
      
      Add a new function cpumask_scnprintf_len() to return the number of
      characters needed to display "len" cpumask bits.  The current method
      of allocating NR_CPUS bytes is incorrect as what's really needed is
      9 characters per 32-bit word of cpumask bits (8 hex digits plus the
      seperator [','] or the terminating NULL.)  This function provides the
      caller the means to allocate the correct string length.
      
      Cc: Paul Jackson <pj@sgi.com>
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      30ca60c1
  25. 05 Nov, 2007 1 commit
  26. 01 Mar, 2007 1 commit
  27. 11 Feb, 2007 1 commit
  28. 11 Oct, 2006 1 commit
    • Reinette Chatre's avatar
      [PATCH] bitmap: parse input from kernel and user buffers · 01a3ee2b
      Reinette Chatre authored
      
      
      lib/bitmap.c:bitmap_parse() is a library function that received as input a
      user buffer.  This seemed to have originated from the way the write_proc
      function of the /proc filesystem operates.
      
      This has been reworked to not use kmalloc and eliminates a lot of
      get_user() overhead by performing one access_ok before using __get_user().
      
      We need to test if we are in kernel or user space (is_user) and access the
      buffer differently.  We cannot use __get_user() to access kernel addresses
      in all cases, for example in architectures with separate address space for
      kernel and user.
      
      This function will be useful for other uses as well; for example, taking
      input for /sysfs instead of /proc, so it was changed to accept kernel
      buffers.  We have this use for the Linux UWB project, as part as the
      upcoming bandwidth allocator code.
      
      Only a few routines used this function and they were changed too.
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@linux.intel.com>
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Joe Korty <joe.korty@ccur.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      01a3ee2b
  29. 25 Jun, 2006 1 commit
  30. 26 Mar, 2006 1 commit
  31. 24 Mar, 2006 3 commits
    • Paul Jackson's avatar
      [PATCH] bitmap: region restructuring · 3cf64b93
      Paul Jackson authored
      
      
      Restructure the bitmap_*_region() operations, to avoid code duplication.
      
      Also reduces binary text size by about 100 bytes (ia64 arch).  The original
      Bottomley bitmap_*_region patch added about 1000 bytes of compiled kernel text
      (ia64).  The Mundt multiword extension added another 600 bytes, and this
      restructuring patch gets back about 100 bytes.
      
      But the real motivation was the reduced amount of duplicated code.
      
      Tested by Paul Mundt using <= BITS_PER_LONG as well as power of
      2 aligned multiword spanning allocations.
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      3cf64b93
    • Paul Mundt's avatar
      [PATCH] bitmap: region multiword spanning support · 74373c6a
      Paul Mundt authored
      
      
      Add support to the lib/bitmap.c bitmap_*_region() routines
      
      For bitmap regions larger than one word (nbits > BITS_PER_LONG).  This removes
      a BUG_ON() in lib bitmap.
      
      I have an updated store queue API for SH that is currently using this with
      relative success, and at first glance, it seems like this could be useful for
      x86 (arch/i386/kernel/pci-dma.c) as well.  Particularly for anything using
      dma_declare_coherent_memory() on large areas and that attempts to allocate
      large buffers from that space.
      
      Paul Jackson also did some cleanup to this patch.
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      74373c6a
    • Paul Jackson's avatar
      [PATCH] bitmap: region cleanup · 87e24802
      Paul Jackson authored
      
      
      Paul Mundt <lethal@linux-sh.org> says:
      
      This patch set implements a number of patches to clean up and restructure the
      bitmap region code, in addition to extending the interface to support
      multiword spanning allocations.
      
      The current implementation (before this patch set) is limited by only being
      able to allocate pages <= BITS_PER_LONG, as noted by the strategically
      positioned BUG_ON() at lib/bitmap.c:752:
      
              /* We don't do regions of pages > BITS_PER_LONG.  The
      	 * algorithm would be a simple look for multiple zeros in the
      	 * array, but there's no driver today that needs this.  If you
      	 * trip this BUG(), you get to code it... */
              BUG_ON(pages > BITS_PER_LONG);
      
      As I seem to have been the first person to trigger this, the result ends up
      being the following patch set with the help of Paul Jackson.
      
      The final patch in the series eliminates quite a bit of code duplication, so
      the bitmap code size ends up being smaller than the current implementation as
      an added bonus.
      
      After these are applied, it should already be possible to do multiword
      allocations with dma_alloc_coherent() out of ranges established by
      dma_declare_coherent_memory() on x86 without having to change any of the code,
      and the SH store queue API will follow up on this as the other user that needs
      support for this.
      
      This patch:
      
      Some code cleanup on the lib/bitmap.c bitmap_*_region() routines:
      
       * spacing
       * variable names
       * comments
      
      Has no change to code function.
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      87e24802
  32. 09 Jan, 2006 1 commit
    • Paul Jackson's avatar
      [PATCH] cpuset: better bitmap remap defaults · 96b7f341
      Paul Jackson authored
      
      
      Fix the default behaviour for the remap operators in bitmap, cpumask and
      nodemask.
      
      As previously submitted, the pair of masks <A, B> defined a map of the
      positions of the set bits in A to the corresponding bits in B.  This is still
      true.
      
      The issue is how to map the other positions, corresponding to the unset (0)
      bits in A.  As previously submitted, they were all mapped to the first set bit
      position in B, a constant map.
      
      When I tried to code per-vma mempolicy rebinding using these remap operators,
      I realized this was wrong.
      
      This patch changes the default to map all the unset bit positions in A to the
      same positions in B, the identity map.
      
      For example, if A has bits 4-7 set, and B has bits 9-12 set, then the map
      defined by the pair <A, B> maps each bit position in the first 32 bits as
      follows:
      
      	0 ==> 0
      	  ...
      	3 ==> 3
      	4 ==> 9
      	  ...
      	7 ==> 12
      	8 ==> 8
      	9 ==> 9
      	  ...
      	31 ==> 31
      
      This now corresponds to the typical behaviour desired when migrating pages and
      policies from one cpuset to another.
      
      The pages on nodes within the original cpuset, and the references in memory
      policies to nodes within the original cpuset, are migrated to the
      corresponding cpuset-relative nodes in the destination cpuset.  Other pages
      and node references are left untouched.
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      96b7f341
  33. 31 Oct, 2005 1 commit
    • Paul Jackson's avatar
      [PATCH] cpusets: bitmap and mask remap operators · fb5eeeee
      Paul Jackson authored
      
      
      In the forthcoming task migration support, a key calculation will be
      mapping cpu and node numbers from the old set to the new set while
      preserving cpuset-relative offset.
      
      For example, if a task and its pages on nodes 8-11 are being migrated to
      nodes 24-27, then pages on node 9 (the 2nd node in the old set) should be
      moved to node 25 (the 2nd node in the new set.)
      
      As with other bitmap operations, the proper way to code this is to provide
      the underlying calculation in lib/bitmap.c, and then to provide the usual
      cpumask and nodemask wrappers.
      
      This patch provides that.  These operations are termed 'remap' operations.
      Both remapping a single bit and a set of bits is supported.
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      fb5eeeee
  34. 25 Jun, 2005 1 commit
  35. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4