From: Miao Xie <miaox@cn.fujitsu.com>
To: David Rientjes <rientjes@google.com>
Cc: Nick Piggin <npiggin@suse.de>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Lee Schermerhorn <lee.schermerhorn@hp.com>
Subject: Re: [regression] cpuset,mm: update tasks' mems_allowed in time (58568d2)
Date: Thu, 25 Feb 2010 09:18:14 +0800 [thread overview]
Message-ID: <4B85CFD6.6010904@cn.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1002241307040.30870@chino.kir.corp.google.com>
on 2010-2-25 5:08, David Rientjes wrote:
> On Wed, 24 Feb 2010, Miao Xie wrote:
>
>> I think it is not a big deal because it is safe and doesn't cause any problem.
>> Beside that, task->cpus_allowed is initialized to cpu_possible_mask on the no-cpuset
>> kernel, so using cpu_possible_mask to initialize task->cpus_allowed is reasonable.
>> (top cpuset is a special cpuset, isn't it?)
>>
>
> I'm suprised that I can create a descendant cpuset of top_cpuset that
> cannot include all of its parents' cpus and that the root cpuset's cpus
> mask doesn't change when cpus are onlined/offlined.
>
top cpuset's cpus is consistent with cpu_online_mask because the kernel changes it
when doing cpu hotplug. So the problem which you said doesn't exist.
Just cpus_allowed of all tasks in the top cpuset is initialized to cpu_possible_mask
in order to avoid updating them when doing cpu hotplug.
WARNING: multiple messages have this Message-ID (diff)
From: Miao Xie <miaox@cn.fujitsu.com>
To: David Rientjes <rientjes@google.com>
Cc: Nick Piggin <npiggin@suse.de>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Lee Schermerhorn <lee.schermerhorn@hp.com>
Subject: Re: [regression] cpuset,mm: update tasks' mems_allowed in time (58568d2)
Date: Thu, 25 Feb 2010 09:18:14 +0800 [thread overview]
Message-ID: <4B85CFD6.6010904@cn.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1002241307040.30870@chino.kir.corp.google.com>
on 2010-2-25 5:08, David Rientjes wrote:
> On Wed, 24 Feb 2010, Miao Xie wrote:
>
>> I think it is not a big deal because it is safe and doesn't cause any problem.
>> Beside that, task->cpus_allowed is initialized to cpu_possible_mask on the no-cpuset
>> kernel, so using cpu_possible_mask to initialize task->cpus_allowed is reasonable.
>> (top cpuset is a special cpuset, isn't it?)
>>
>
> I'm suprised that I can create a descendant cpuset of top_cpuset that
> cannot include all of its parents' cpus and that the root cpuset's cpus
> mask doesn't change when cpus are onlined/offlined.
>
top cpuset's cpus is consistent with cpu_online_mask because the kernel changes it
when doing cpu hotplug. So the problem which you said doesn't exist.
Just cpus_allowed of all tasks in the top cpuset is initialized to cpu_possible_mask
in order to avoid updating them when doing cpu hotplug.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-02-25 1:18 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-18 13:49 [regression] cpuset,mm: update tasks' mems_allowed in time (58568d2) Nick Piggin
2010-02-18 13:49 ` Nick Piggin
2010-02-18 21:38 ` David Rientjes
2010-02-18 21:38 ` David Rientjes
2010-02-19 3:31 ` Nick Piggin
2010-02-19 3:31 ` Nick Piggin
2010-02-19 10:06 ` David Rientjes
2010-02-19 10:06 ` David Rientjes
2010-02-22 11:53 ` Miao Xie
2010-02-22 11:53 ` Miao Xie
2010-02-22 12:06 ` Nick Piggin
2010-02-22 12:06 ` Nick Piggin
2010-02-23 1:48 ` Miao Xie
2010-02-23 1:48 ` Miao Xie
2010-02-22 22:06 ` David Rientjes
2010-02-22 22:06 ` David Rientjes
2010-02-23 7:32 ` Miao Xie
2010-02-23 7:32 ` Miao Xie
2010-02-23 8:55 ` David Rientjes
2010-02-23 8:55 ` David Rientjes
2010-02-23 9:23 ` Miao Xie
2010-02-23 9:23 ` Miao Xie
2010-02-23 22:31 ` David Rientjes
2010-02-23 22:31 ` David Rientjes
2010-02-24 9:35 ` Miao Xie
2010-02-24 9:35 ` Miao Xie
2010-02-24 21:08 ` David Rientjes
2010-02-24 21:08 ` David Rientjes
2010-02-25 1:18 ` Miao Xie [this message]
2010-02-25 1:18 ` Miao Xie
2010-02-22 12:12 ` Nick Piggin
2010-02-22 12:12 ` Nick Piggin
2010-02-22 22:00 ` David Rientjes
2010-02-22 22:00 ` David Rientjes
2010-02-23 8:25 ` Miao Xie
2010-02-23 8:25 ` Miao Xie
2010-02-23 8:44 ` David Rientjes
2010-02-23 8:44 ` David Rientjes
2010-02-24 9:49 ` Miao Xie
2010-02-24 9:49 ` Miao Xie
2010-02-24 21:06 ` David Rientjes
2010-02-24 21:06 ` David Rientjes
2010-02-19 7:51 ` KOSAKI Motohiro
2010-02-19 7:51 ` KOSAKI Motohiro
2010-02-19 9:42 ` David Rientjes
2010-02-19 9:42 ` David Rientjes
2010-02-19 7:56 ` KAMEZAWA Hiroyuki
2010-02-19 7:56 ` KAMEZAWA Hiroyuki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B85CFD6.6010904@cn.fujitsu.com \
--to=miaox@cn.fujitsu.com \
--cc=lee.schermerhorn@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.