Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933673AbZGQAEw (ORCPT ); Thu, 16 Jul 2009 20:04:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933313AbZGQAEw (ORCPT ); Thu, 16 Jul 2009 20:04:52 -0400 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:55014 "EHLO fgwmail5.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933310AbZGQAEv (ORCPT ); Thu, 16 Jul 2009 20:04:51 -0400 X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 From: KOSAKI Motohiro To: David Rientjes Subject: Re: [BUG] set_mempolicy(MPOL_INTERLEAV) cause kernel panic Cc: kosaki.motohiro@jp.fujitsu.com, Lee Schermerhorn , Miao Xie , Ingo Molnar , Peter Zijlstra , Christoph Lameter , Paul Menage , Nick Piggin , Yasunori Goto , Pekka Enberg , linux-mm , LKML , Andrew Morton In-Reply-To: References: <1247679064.4089.26.camel@useless.americas.hpqcorp.net> Message-Id: <20090717090003.A903.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.07 [ja] Date: Fri, 17 Jul 2009 09:04:46 +0900 (JST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2469 Lines: 75 > On Wed, 15 Jul 2009, Lee Schermerhorn wrote: > > > Interestingly, on ia64, the top cpuset mems_allowed gets set to all > > possible nodes, while on x86_64, it gets set to on-line nodes [or nodes > > with memory]. Maybe this is a to support hot-plug? > > > > numactl --interleave=all simply passes a nodemask with all bits set, so if > cpuset_current_mems_allowed includes offline nodes from node_possible_map, > then mpol_set_nodemask() doesn't mask them off. > > Seems like we could handle this strictly in mempolicies without worrying > about top_cpuset like in the following? This patch seems band-aid patch. it will change memory-hotplug behavior. Please imazine following scenario: 1. numactl interleave=all process-A 2. memory hot-add before 2.6.30: -> process-A can use hot-added memory your proposal patch: -> process-A can't use hot-added memory > --- > diff --git a/mm/mempolicy.c b/mm/mempolicy.c > --- a/mm/mempolicy.c > +++ b/mm/mempolicy.c > @@ -194,6 +194,7 @@ static int mpol_new_bind(struct mempolicy *pol, const nodemask_t *nodes) > static int mpol_set_nodemask(struct mempolicy *pol, const nodemask_t *nodes) > { > nodemask_t cpuset_context_nmask; > + nodemask_t mems_allowed; > int ret; > > /* if mode is MPOL_DEFAULT, pol is NULL. This is right. */ > @@ -201,20 +202,21 @@ static int mpol_set_nodemask(struct mempolicy *pol, const nodemask_t *nodes) > return 0; > > VM_BUG_ON(!nodes); > + nodes_and(mems_allowed, cpuset_current_mems_allowed, > + node_states[N_HIGH_MEMORY]); > if (pol->mode == MPOL_PREFERRED && nodes_empty(*nodes)) > nodes = NULL; /* explicit local allocation */ > else { > if (pol->flags & MPOL_F_RELATIVE_NODES) > mpol_relative_nodemask(&cpuset_context_nmask, nodes, > - &cpuset_current_mems_allowed); > + &mems_allowed); > else > nodes_and(cpuset_context_nmask, *nodes, > - cpuset_current_mems_allowed); > + mems_allowed); > if (mpol_store_user_nodemask(pol)) > pol->w.user_nodemask = *nodes; > else > - pol->w.cpuset_mems_allowed = > - cpuset_current_mems_allowed; > + pol->w.cpuset_mems_allowed = mems_allowed; > } > > ret = mpol_ops[pol->mode].create(pol, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/