All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Menage <menage@google.com>
To: miaox@cn.fujitsu.com
Cc: Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cpuset: fix allocating page cache/slab object on the  unallowed node when memory spread is set
Date: Wed, 21 Jan 2009 02:41:56 -0800	[thread overview]
Message-ID: <6599ad830901210241y1fe96d93x462e23d9883e7ab5@mail.gmail.com> (raw)
In-Reply-To: <4976D77C.3020107@cn.fujitsu.com>

On Wed, Jan 21, 2009 at 12:06 AM, Miao Xie <miaox@cn.fujitsu.com> wrote:
> The task still allocated the page caches on old node after modifying its
> cpuset's mems when 'memory_spread_page' was set, it is caused by the old
> mem_allowed_list of the task, the current kernel doesn't updates it unless some
> function invokes cpuset_update_task_memory_state(), it is too late sometimes.

Can you give a more concrete example of how the current code can break?

> We must update the mem_allowed_list of the tasks in time.

This is a fairly fundamental change to the way that mems_allowed is
handled - it dates back to fairly early in cpusets' history.

> - * The task_struct fields mems_allowed and mems_generation may only
> - * be accessed in the context of that task, so require no locks.
> + * The task_struct fields mems_allowed may only be accessed in the context
> + * of that task, so require no locks.

This comment is no longer true, since mems_allowed is now being
updated by other processes.

What's to stop a task reading current->mems_allowed and racing with an
update from update_tasks_nodemask() ? Or else, why can that not lead
to badness?

Paul

  parent reply	other threads:[~2009-01-21 10:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-21  8:06 [PATCH] cpuset: fix allocating page cache/slab object on the unallowed node when memory spread is set Miao Xie
2009-01-21  8:30 ` Nick Piggin
2009-01-21 10:41 ` Paul Menage [this message]
2009-02-03  3:05   ` Miao Xie
2009-01-27 22:42 ` Andrew Morton
2009-01-28 16:38   ` Christoph Lameter
2009-02-03  3:25   ` Miao Xie
2009-02-03 22:16     ` Andrew Morton
2009-02-03 22:49       ` Paul Menage
2009-02-04  9:31         ` Miao Xie
2009-02-06 19:19           ` Paul Menage
2009-02-09  4:02             ` Nick Piggin
2009-02-10 11:37               ` Paul Menage
2009-02-12  0:54                 ` Nick Piggin
2009-02-12  1:19                   ` Paul Menage
2009-02-12  1:55                     ` Nick Piggin
2009-02-12  1:58                       ` Paul Menage
2009-02-12  8:23                       ` Miao Xie
2009-02-12 21:53                         ` Paul Menage
2009-02-12  8:27                       ` Miao Xie
2009-02-12 10:40                         ` Nick Piggin
2009-02-12  5:57                     ` Miao Xie
2009-02-12 11:06                       ` Paul Jackson
2009-02-04  9:03       ` Miao Xie

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=6599ad830901210241y1fe96d93x462e23d9883e7ab5@mail.gmail.com \
    --to=menage@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miaox@cn.fujitsu.com \
    --cc=mingo@elte.hu \
    /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.