Re: [PATCH for-3.3] mempool: clean up and document synchronizationand memory barrier usage

[Oleg Nesterov]

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/