Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756200Ab0BXJuW (ORCPT ); Wed, 24 Feb 2010 04:50:22 -0500 Received: from cn.fujitsu.com ([222.73.24.84]:53238 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1755706Ab0BXJuV (ORCPT ); Wed, 24 Feb 2010 04:50:21 -0500 Message-ID: <4B84F645.6030404@cn.fujitsu.com> Date: Wed, 24 Feb 2010 17:49:57 +0800 From: Miao Xie Reply-To: miaox@cn.fujitsu.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: David Rientjes CC: Nick Piggin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Lee Schermerhorn Subject: Re: [regression] cpuset,mm: update tasks' mems_allowed in time (58568d2) References: <20100218134921.GF9738@laptop> <20100219033126.GI9738@laptop> <20100222121222.GV9738@laptop> <4B839103.2060901@cn.fujitsu.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1329 Lines: 34 on 2010-2-23 16:44, David Rientjes wrote: > On Tue, 23 Feb 2010, Miao Xie wrote: > >> Sorry, Could you explain what you advised? >> I think it is hard to fix this problem by adding a variant, because it is >> hard to avoid loading a word of the mask before >> >> nodes_or(tsk->mems_allowed, tsk->mems_allowed, *newmems); >> >> and then loading another word of the mask after >> >> tsk->mems_allowed = *newmems; >> >> unless we use lock. >> >> Maybe we need a rw-lock to protect task->mems_allowed. >> > > I meant that we need to define synchronization only for configurations > that do not do atomic nodemask_t stores, it's otherwise unnecessary. > We'll need to load and store tsk->mems_allowed via a helper function that > is defined to take the rwlock for such configs and only read/write the > nodemask for others. > By investigating, we found that it is hard to guarantee the consistent between mempolicy and mems_allowed because mempolicy was designed as a self-update function. it just can be changed by one's self. Maybe we must change the implement of mempolicy. -- 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/