lkml.org 
[lkml]   [2010]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 4/4] cpuset,mm: use rwlock to protect task->mempolicy and mems_allowed
    on 2010-3-10 3:42, Paul Menage wrote:
    > On Sat, Mar 6, 2010 at 6:33 PM, Miao Xie <miaox@cn.fujitsu.com> wrote:
    >>
    >> Before applying this patch, cpuset updates task->mems_allowed just like
    >> what you said. But the allocator is still likely to see an empty nodemask.
    >> This problem have been pointed out by Nick Piggin.
    >>
    >> The problem is following:
    >> The size of nodemask_t is greater than the size of long integer, so loading
    >> and storing of nodemask_t are not atomic operations. If task->mems_allowed
    >> don't intersect with new_mask, such as the first word of the mask is empty
    >> and only the first word of new_mask is not empty. When the allocator
    >> loads a word of the mask before
    >>
    >> current->mems_allowed |= new_mask;
    >>
    >> and then loads another word of the mask after
    >>
    >> current->mems_allowed = new_mask;
    >>
    >> the allocator gets an empty nodemask.
    >
    > Couldn't that be solved by having the reader read the nodemask twice
    > and compare them? In the normal case there's no race, so the second
    > read is straight from L1 cache and is very cheap. In the unlikely case
    > of a race, the reader would keep trying until it got two consistent
    > values in a row.

    I think this method can't fix the problem because we can guarantee the second
    read is after the update of mask completes.

    Thanks!
    Miao

    >
    > Paul
    >
    >
    >




    \
     
     \ /
      Last update: 2010-03-11 06:07    [W:0.038 / U:0.000 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site