Messages in this thread | | | Date | Thu, 13 May 2010 14:16:33 +0800 | From | Miao Xie <> | Subject | Re: [PATCH -mm] cpuset,mm: fix no node to alloc memory when changing cpuset's mems - fix2 |
| |
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
| |