lkml.org 
[lkml]   [2011]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2011-12-21 16:05    [W:0.111 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site