Re: [PATCH] cpuset: fix allocating page cache/slab object on the unallowed node when memory spread is set

[Paul Menage]

On Wed, Feb 11, 2009 at 4:54 PM, Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:
>
> It would be possible, depending on timing, for the allocating thread to
> see either pre or post mems_allowed even if access was fully locked.

Right - seeing either the pre set or the post set is fine.

>
> The only difference is that a partially changed mems_allowed could be
> seen. But what does this really mean? Some combination of the new and
> the old nodes. I don't think this is too much of a problem.

But if the old and new nodes are disjoint, that could lead to seeing no nodes.

Also, having the results of cpuset_zone_allowed() and
cpuset_current_mems_allowed change at random times over the course of
a call to alloc_pages() might cause interesting effects (e.g. we make
progress freeing pages from one set of nodes, and then call
get_page_from_freelist() on a different set of nodes).

>
> This could work if we *really* need an atomic snapshot of mems_allowed.
> seqcount synchronisation would be an alternative too that could allow
> sleeping more easily than SRCU (OTOH if you don't need sleeping, then
> RCU should be faster than seqcount).
>
> But I'm not convinced we do need this to be atomic.

It's possible that I'm being overly-paranoid here. The decision to
make mems_allowed updates be purely pulled by the task itself predates
my involvement with cpusets code by a long time. Paul Jackson (CC'd)
may have opinions here, but I suspect his sgi.com email address no
longer works, and I don't have any more recent address for him.

Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/