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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>