Messages in this thread | | | Date | Wed, 21 Dec 2011 15:57:14 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH for-3.3] mempool: clean up and document synchronization and memory barrier usage |
| |
On 12/21, Oleg Nesterov wrote: > > On 12/20, Tejun Heo wrote: > > > > Furthermore, mempool_alloc() is already holding pool->lock when it > > decides that it needs to wait. There is no reason to do unlock - add > > waitqueue - test condition again. It can simply add itself to > > waitqueue while holding pool->lock and then unlock and sleep. > > Confused. I agree, we can hold pool->lock until schedule(). But, at > the same time, why should we hold it?
Ah, I see.
> Or I missed the reason why we must not unlock before prepare_to_wait?
I didn't notice that this removes another "if (!pool->curr_nr)" check.
Oleg.
| |