on 2010-5-13 1:48, Andrew Morton wrote: >> It may cause the performance regression, so I do my best to abstain from using a real >> lock. > > Well, the code as-is is pretty exotic with lots of open-coded tricky > barriers - it's best to avoid inventing new primitives if possible. > For example, there's no lockdep support for this new "lock". I didn't find an existing lock that could fix the problem well till now, so I had to design this new "lock" to protect the task's mempolicy and mems_allowed. > > mutex_lock() is pretty quick - basically a simgle atomic op. How > frequently do these operations occur? There is another problem that I forgot to mention. besides the performance problem, the read-side may call it in the context in which the task can't sleep. so we can't use mutex. > > The code you have at present is fairly similar to sequence locks. I > wonder if there's some way of (ab)using sequence locks for this. > seqlocks don't have lockdep support either... > We can't use sequence locks here, because the read-side may read the data in changing, but it can't put off cleaning the old bits. Thanks Miao -- 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>