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:6.777 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site