1. 19 May, 2016 1 commit
  2. 13 Feb, 2015 2 commits
    • Tejun Heo's avatar
      bitmap, cpumask, nodemask: remove dedicated formatting functions · 46385326
      Tejun Heo authored
      Now that all bitmap formatting usages have been converted to
      '%*pb[l]', the separate formatting functions are unnecessary.  The
      following functions are removed.
      
      * bitmap_scn[list]printf()
      * cpumask_scnprintf(), cpulist_scnprintf()
      * [__]nodemask_scnprintf(), [__]nodelist_scnprintf()
      * seq_bitmap[_list](), seq_cpumask[_list](), seq_nodemask[_list]()
      * seq_buf_bitmask()
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      46385326
    • Tejun Heo's avatar
      cpumask, nodemask: implement cpumask/nodemask_pr_args() · f1bbc032
      Tejun Heo authored
      printf family of functions can now format bitmaps using '%*pb[l]' and
      all cpumask and nodemask formatting will be converted to use it.  To
      ease printing these masks with '%*pb[l]' which require two params -
      the number of bits and the actual bitmap, this patch implement
      cpumask_pr_args() and nodemask_pr_args() which can be used to provide
      arguments for '%*pb[l]'
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Li Zefan <lizefan@huawei.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f1bbc032
  3. 12 Feb, 2015 1 commit
  4. 06 Aug, 2014 1 commit
  5. 25 Jul, 2013 1 commit
    • Tom Rini's avatar
      numa: Mark __node_set() as __always_inline · 323f54ed
      Tom Rini authored
      It is posible for some compilers to decide that __node_set() does
      not need to be made turned into an inline function.  When the
      compiler does this on an __init function calling it on
      __initdata we get a section mismatch warning now.  Use
      __always_inline to ensure that we will be inlined.
      Reported-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Cc: Jianpeng Ma <majianpeng@gmail.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Wen Congyang <wency@cn.fujitsu.com>
      Cc: Jiang Liu <jiang.liu@huawei.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Minchan Kim <minchan.kim@gmail.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarTom Rini <trini@ti.com>
      Link: http://lkml.kernel.org/r/1374776770-32361-1-git-send-email-trini@ti.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      323f54ed
  6. 12 Dec, 2012 2 commits
    • Lai Jiangshan's avatar
      numa: add CONFIG_MOVABLE_NODE for movable-dedicated node · 20b2f52b
      Lai Jiangshan authored
      We need a node which only contains movable memory.  This feature is very
      important for node hotplug.  If a node has normal/highmem, the memory may
      be used by the kernel and can't be offlined.  If the node only contains
      movable memory, we can offline the memory and the node.
      
      All are prepared, we can actually introduce N_MEMORY.
      add CONFIG_MOVABLE_NODE make we can use it for movable-dedicated node
      
      [akpm@linux-foundation.org: fix Kconfig text]
      Signed-off-by: default avatarLai Jiangshan <laijs@cn.fujitsu.com>
      Tested-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: default avatarWen Congyang <wency@cn.fujitsu.com>
      Cc: Jiang Liu <jiang.liu@huawei.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Minchan Kim <minchan.kim@gmail.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      20b2f52b
    • Lai Jiangshan's avatar
      mm: node_states: introduce N_MEMORY · 8219fc48
      Lai Jiangshan authored
      We have N_NORMAL_MEMORY for standing for the nodes that have normal memory
      with zone_type <= ZONE_NORMAL.
      
      And we have N_HIGH_MEMORY for standing for the nodes that have normal or
      high memory.
      
      But we don't have any word to stand for the nodes that have *any* memory.
      
      And we have N_CPU but without N_MEMORY.
      
      Current code reuse the N_HIGH_MEMORY for this purpose because any node
      which has memory must have high memory or normal memory currently.
      
      A)	But this reusing is bad for *readability*. Because the name
      	N_HIGH_MEMORY just stands for high or normal:
      
      A.example 1)
      	mem_cgroup_nr_lru_pages():
      		for_each_node_state(nid, N_HIGH_MEMORY)
      
      	The user will be confused(why this function just counts for high or
      	normal memory node? does it counts for ZONE_MOVABLE's lru pages?)
      	until someone else tell them N_HIGH_MEMORY is reused to stand for
      	nodes that have any memory.
      
      A.cont) If we introduce N_MEMORY, we can reduce this confusing
      	AND make the code more clearly:
      
      A.example 2) mm/page_cgroup.c use N_HIGH_MEMORY twice:
      
      	One is in page_cgroup_init(void):
      		for_each_node_state(nid, N_HIGH_MEMORY) {
      
      	It means if the node have memory, we will allocate page_cgroup map for
      	the node. We should use N_MEMORY instead here to gaim more clearly.
      
      	The second using is in alloc_page_cgroup():
      		if (node_state(nid, N_HIGH_MEMORY))
      			addr = vzalloc_node(size, nid);
      
      	It means if the node has high or normal memory that can be allocated
      	from kernel. We should keep N_HIGH_MEMORY here, and it will be better
      	if the "any memory" semantic of N_HIGH_MEMORY is removed.
      
      B)	This reusing is out-dated if we introduce MOVABLE-dedicated node.
      	The MOVABLE-dedicated node should not appear in
      	node_stats[N_HIGH_MEMORY] nor node_stats[N_NORMAL_MEMORY],
      	because MOVABLE-dedicated node has no high or normal memory.
      
      	In x86_64, N_HIGH_MEMORY=N_NORMAL_MEMORY, if a MOVABLE-dedicated node
      	is in node_stats[N_HIGH_MEMORY], it is also means it is in
      	node_stats[N_NORMAL_MEMORY], it causes SLUB wrong.
      
      	The slub uses
      		for_each_node_state(nid, N_NORMAL_MEMORY)
      	and creates kmem_cache_node for MOVABLE-dedicated node and cause problem.
      
      In one word, we need a N_MEMORY.  We just intrude it as an alias to
      N_HIGH_MEMORY and fix all im-proper usages of N_HIGH_MEMORY in late
      patches.
      Signed-off-by: default avatarLai Jiangshan <laijs@cn.fujitsu.com>
      Acked-by: default avatarChristoph Lameter <cl@linux.com>
      Acked-by: default avatarHillf Danton <dhillf@gmail.com>
      Signed-off-by: default avatarWen Congyang <wency@cn.fujitsu.com>
      Cc: Lin Feng <linfeng@cn.fujitsu.com>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8219fc48
  7. 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
  8. 30 May, 2010 1 commit
  9. 27 May, 2010 1 commit
  10. 12 Mar, 2010 1 commit
  11. 06 Mar, 2010 1 commit
  12. 15 Dec, 2009 3 commits
    • David Rientjes's avatar
      mm: add gfp flags for NODEMASK_ALLOC slab allocations · bad44b5b
      David Rientjes authored
      Objects passed to NODEMASK_ALLOC() are relatively small in size and are
      backed by slab caches that are not of large order, traditionally never
      greater than PAGE_ALLOC_COSTLY_ORDER.
      
      Thus, using GFP_KERNEL for these allocations on large machines when
      CONFIG_NODES_SHIFT > 8 will cause the page allocator to loop endlessly in
      the allocation attempt, each time invoking both direct reclaim or the oom
      killer.
      
      This is of particular interest when using NODEMASK_ALLOC() from a
      mempolicy context (either directly in mm/mempolicy.c or the mempolicy
      constrained hugetlb allocations) since the oom killer always kills current
      when allocations are constrained by mempolicies.  So for all present use
      cases in the kernel, current would end up being oom killed when direct
      reclaim fails.  That would allow the NODEMASK_ALLOC() to succeed but
      current would have sacrificed itself upon returning.
      
      This patch adds gfp flags to NODEMASK_ALLOC() to pass to kmalloc() on
      CONFIG_NODES_SHIFT > 8; this parameter is a nop on other configurations.
      All current use cases either directly from hugetlb code or indirectly via
      NODEMASK_SCRATCH() union __GFP_NORETRY to avoid direct reclaim and the oom
      killer when the slab allocator needs to allocate additional pages.
      
      The side-effect of this change is that all current use cases of either
      NODEMASK_ALLOC() or NODEMASK_SCRATCH() need appropriate -ENOMEM handling
      when the allocation fails (never for CONFIG_NODES_SHIFT <= 8).  All
      current use cases were audited and do have appropriate error handling at
      this time.
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Acked-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Nishanth Aravamudan <nacc@us.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Adam Litke <agl@us.ibm.com>
      Cc: Andy Whitcroft <apw@canonical.com>
      Cc: Eric Whitney <eric.whitney@hp.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bad44b5b
    • Lee Schermerhorn's avatar
      hugetlb: factor init_nodemask_of_node() · c1e6c8d0
      Lee Schermerhorn authored
      Factor init_nodemask_of_node() out of the nodemask_of_node() macro.
      
      This will be used to populate the huge pages "nodes_allowed" nodemask for
      a single node when basing nodes_allowed on a preferred/local mempolicy or
      when a persistent huge page pool page count is modified via a per node
      sysfs attribute.
      Signed-off-by: default avatarLee Schermerhorn <lee.schermerhorn@hp.com>
      Acked-by: default avatarMel Gorman <mel@csn.ul.ie>
      Reviewed-by: default avatarAndi Kleen <andi@firstfloor.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Nishanth Aravamudan <nacc@us.ibm.com>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Adam Litke <agl@us.ibm.com>
      Cc: Andy Whitcroft <apw@canonical.com>
      Cc: Eric Whitney <eric.whitney@hp.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c1e6c8d0
    • David Rientjes's avatar
      nodemask: make NODEMASK_ALLOC more general · 4e7b8a6c
      David Rientjes authored
      This is a series of patches to provide control over the location of the
      allocation and freeing of persistent huge pages on a NUMA platform.
      Please consider for merging into mmotm.
      
      This series uses two mechanisms to constrain the nodes from which
      persistent huge pages are allocated: 1) the task NUMA mempolicy of the
      task modifying a new sysctl "nr_hugepages_mempolicy", based on a
      suggestion by Mel Gorman; and 2) a subset of the hugepages hstate sysfs
      attributes have been added [in V4] to each node system device under:
      
      	/sys/devices/node/node[0-9]*/hugepages
      
      The per node attibutes allow direct assignment of a huge page count on a
      specific node, regardless of the task's mempolicy or cpuset constraints.
      
      This patch:
      
      NODEMASK_ALLOC(x, m) assumes x is a type of struct, which is unnecessary.
      It's perfectly reasonable to use this macro to allocate a nodemask_t,
      which is anonymous, either dynamically or on the stack depending on
      NODES_SHIFT.
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Signed-off-by: default avatarLee Schermerhorn <lee.schermerhorn@hp.com>
      Acked-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Nishanth Aravamudan <nacc@us.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Adam Litke <agl@us.ibm.com>
      Cc: Andy Whitcroft <apw@canonical.com>
      Cc: Eric Whitney <eric.whitney@hp.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4e7b8a6c
  13. 07 Aug, 2009 1 commit
    • KAMEZAWA Hiroyuki's avatar
      mm: make set_mempolicy(MPOL_INTERLEAV) N_HIGH_MEMORY aware · 4bfc4495
      KAMEZAWA Hiroyuki authored
      At first, init_task's mems_allowed is initialized as this.
       init_task->mems_allowed == node_state[N_POSSIBLE]
      
      And cpuset's top_cpuset mask is initialized as this
       top_cpuset->mems_allowed = node_state[N_HIGH_MEMORY]
      
      Before 2.6.29:
      policy's mems_allowed is initialized as this.
      
        1. update tasks->mems_allowed by its cpuset->mems_allowed.
        2. policy->mems_allowed = nodes_and(tasks->mems_allowed, user's mask)
      
      Updating task's mems_allowed in reference to top_cpuset's one.
      cpuset's mems_allowed is aware of N_HIGH_MEMORY, always.
      
      In 2.6.30: After commit 58568d2a
      ("cpuset,mm: update tasks' mems_allowed in time"), policy's mems_allowed
      is initialized as this.
      
        1. policy->mems_allowd = nodes_and(task->mems_allowed, user's mask)
      
      Here, if task is in top_cpuset, task->mems_allowed is not updated from
      init's one.  Assume user excutes command as #numactrl --interleave=all
      ,....
      
        policy->mems_allowd = nodes_and(N_POSSIBLE, ALL_SET_MASK)
      
      Then, policy's mems_allowd can includes a possible node, which has no pgdat.
      
      MPOL's INTERLEAVE just scans nodemask of task->mems_allowd and access this
      directly.
      
        NODE_DATA(nid)->zonelist even if NODE_DATA(nid)==NULL
      
      Then, what's we need is making policy->mems_allowed be aware of
      N_HIGH_MEMORY.  This patch does that.  But to do so, extra nodemask will
      be on statck.  Because I know cpumask has a new interface of
      CPUMASK_ALLOC(), I added it to node.
      
      This patch stands on old behavior.  But I feel this fix itself is just a
      Band-Aid.  But to do fundametal fix, we have to take care of memory
      hotplug and it takes time.  (task->mems_allowd should be N_HIGH_MEMORY, I
      think.)
      
      mpol_set_nodemask() should be aware of N_HIGH_MEMORY and policy's nodemask
      should be includes only online nodes.
      
      In old behavior, this is guaranteed by frequent reference to cpuset's
      code.  Now, most of them are removed and mempolicy has to check it by
      itself.
      
      To do check, a few nodemask_t will be used for calculating nodemask.  But,
      size of nodemask_t can be big and it's not good to allocate them on stack.
      
      Now, cpumask_t has CPUMASK_ALLOC/FREE an easy code for get scratch area.
      NODEMASK_ALLOC/FREE shoudl be there.
      
      [akpm@linux-foundation.org: cleanups & tweaks]
      Tested-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Miao Xie <miaox@cn.fujitsu.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Paul Menage <menage@google.com>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4bfc4495
  14. 16 Jun, 2009 1 commit
  15. 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
  16. 16 Oct, 2007 3 commits
    • Christoph Lameter's avatar
      Memoryless nodes: Add N_CPU node state · 37c0708d
      Christoph Lameter authored
      We need the check for a node with cpu in zone reclaim.  Zone reclaim will not
      allow remote zone reclaim if a node has a cpu.
      
      [Lee.Schermerhorn@hp.com: Move setup of N_CPU node state mask]
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Tested-by: default avatarLee Schermerhorn <lee.schermerhorn@hp.com>
      Acked-by: default avatarBob Picco <bob.picco@hp.com>
      Cc: Nishanth Aravamudan <nacc@us.ibm.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Mel Gorman <mel@skynet.ie>
      Signed-off-by: default avatarLee Schermerhorn <lee.schermerhorn@hp.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      37c0708d
    • Christoph Lameter's avatar
      Memoryless nodes: introduce mask of nodes with memory · 7ea1530a
      Christoph Lameter authored
      It is necessary to know if nodes have memory since we have recently begun to
      add support for memoryless nodes.  For that purpose we introduce a two new
      node states: N_HIGH_MEMORY and N_NORMAL_MEMORY.
      
      A node has its bit in N_HIGH_MEMORY set if it has any memory regardless of the
      type of mmemory.  If a node has memory then it has at least one zone defined
      in its pgdat structure that is located in the pgdat itself.
      
      A node has its bit in N_NORMAL_MEMORY set if it has a lower zone than
      ZONE_HIGHMEM.  This means it is possible to allocate memory that is not
      subject to kmap.
      
      N_HIGH_MEMORY and N_NORMAL_MEMORY can then be used in various places to insure
      that we do the right thing when we encounter a memoryless node.
      
      [akpm@linux-foundation.org: build fix]
      [Lee.Schermerhorn@hp.com: update N_HIGH_MEMORY node state for memory hotadd]
      [y-goto@jp.fujitsu.com: Fix memory hotplug + sparsemem build]
      Signed-off-by: default avatarLee Schermerhorn <Lee.Schermerhorn@hp.com>
      Signed-off-by: default avatarNishanth Aravamudan <nacc@us.ibm.com>
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Acked-by: default avatarBob Picco <bob.picco@hp.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Mel Gorman <mel@skynet.ie>
      Signed-off-by: default avatarYasunori Goto <y-goto@jp.fujitsu.com>
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7ea1530a
    • Christoph Lameter's avatar
      Memoryless nodes: Generic management of nodemasks for various purposes · 13808910
      Christoph Lameter authored
      Why do we need to support memoryless nodes?
      
      KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
      
      > For fujitsu, problem is called "empty" node.
      >
      > When ACPI's SRAT table includes "possible nodes", ia64 bootstrap(acpi_numa_init)
      > creates nodes, which includes no memory, no cpu.
      >
      > I tried to remove empty-node in past, but that was denied.
      > It was because we can hot-add cpu to the empty node.
      > (node-hotplug triggered by cpu is not implemented now. and it will be ugly.)
      >
      >
      > For HP, (Lee can comment on this later), they have memory-less-node.
      > As far as I hear, HP's machine can have following configration.
      >
      > (example)
      > Node0: CPU0   memory AAA MB
      > Node1: CPU1   memory AAA MB
      > Node2: CPU2   memory AAA MB
      > Node3: CPU3   memory AAA MB
      > Node4: Memory XXX GB
      >
      > AAA is very small value (below 16MB)  and will be omitted by ia64 bootstrap.
      > After boot, only Node 4 has valid memory (but have no cpu.)
      >
      > Maybe this is memory-interleave by firmware config.
      
      Christoph Lameter <clameter@sgi.com> wrote:
      
      > Future SGI platforms (actually also current one can have but nothing like
      > that is deployed to my knowledge) have nodes with only cpus. Current SGI
      > platforms have nodes with just I/O that we so far cannot manage in the
      > core. So the arch code maps them to the nearest memory node.
      
      Lee Schermerhorn <Lee.Schermerhorn@hp.com> wrote:
      
      > For the HP platforms, we can configure each cell with from 0% to 100%
      > "cell local memory".  When we configure with <100% CLM, the "missing
      > percentages" are interleaved by hardware on a cache-line granularity to
      > improve bandwidth at the expense of latency for numa-challenged
      > applications [and OSes, but not our problem ;-)].  When we boot Linux on
      > such a config, all of the real nodes have no memory--it all resides in a
      > single interleaved pseudo-node.
      >
      > When we boot Linux on a 100% CLM configuration [== NUMA], we still have
      > the interleaved pseudo-node.  It contains a few hundred MB stolen from
      > the real nodes to contain the DMA zone.  [Interleaved memory resides at
      > phys addr 0].  The memoryless-nodes patches, along with the zoneorder
      > patches, support this config as well.
      >
      > Also, when we boot a NUMA config with the "mem=" command line,
      > specifying less memory than actually exists, Linux takes the excluded
      > memory "off the top" rather than distributing it across the nodes.  This
      > can result in memoryless nodes, as well.
      >
      
      This patch:
      
      Preparation for memoryless node patches.
      
      Provide a generic way to keep nodemasks describing various characteristics of
      NUMA nodes.
      
      Remove the node_online_map and the node_possible map and realize the same
      functionality using two nodes stats: N_POSSIBLE and N_ONLINE.
      
      [Lee.Schermerhorn@hp.com: Initialize N_*_MEMORY and N_CPU masks for non-NUMA config]
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Tested-by: default avatarLee Schermerhorn <lee.schermerhorn@hp.com>
      Acked-by: default avatarLee Schermerhorn <lee.schermerhorn@hp.com>
      Acked-by: default avatarBob Picco <bob.picco@hp.com>
      Cc: Nishanth Aravamudan <nacc@us.ibm.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Mel Gorman <mel@skynet.ie>
      Signed-off-by: default avatarLee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: "Serge E. Hallyn" <serge@hallyn.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      13808910
  17. 20 Feb, 2007 1 commit
  18. 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
  19. 02 Oct, 2006 1 commit
  20. 27 Mar, 2006 1 commit
  21. 07 Feb, 2006 1 commit
  22. 30 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
  23. 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