cvs commit: src/sys/vm uma_core.c

[Mohan Srinivasan]

Hi Gleb,

I did look at the case where the uma_zfree_arg() would free the object back
to the cache and not wake up the processes. uma_zfree_arg() checks for 
ZFLAG_FULL, when that is set it calls uma_zfree_internal(). The wakeup will 
happen from uma_zfree_internal().

mohan

--- Gleb Smirnoff <glebius at FreeBSD.org> wrote:

>   Mohan,
> 
> On Wed, Jan 24, 2007 at 10:49:12PM +0000, Mohan Srinivasan wrote:
> M> mohans      2007-01-24 22:49:12 UTC
> M> 
> M>   FreeBSD src repository
> M> 
> M>   Modified files:
> M>     sys/vm               uma_core.c 
> M>   Log:
> M>   Fix for a bug where only one process (of multiple) blocked on
> M>   maxpages on a zone is woken up, with the rest never being woken up as
> M>   a result of the ZFLAG_FULL flag being cleared. Wakeup all such blocked
> M>   procsses instead. This change introduces a thundering herd, but since
> M>   this should be relatively infrequent, optimizing this (by introducing
> M>   a count of blocked processes, for example) may be premature.
> M>   
> M>   Reviewd by: ups@
> 
>   I hope this should fix some problems, we are observing. Thanks for
> working on this!
> 
>   But I wonder, can the following happen. Under high memory pressure,
> a zone with a limit is exhausted and several processes are waiting
> for memory in this zone. Then a few items are freed, and they are freed
> to the per cpu cache, not to the zone cache. Thus, the wakeup() isn't
> issued, and waiting processes keep waiting forever. Then, some new
> processes can allocate an item from the per cpu cache and free it back
> to the per cpu cache, and again waiting processes won't be waked.
> 
> I've observed and sshd sleeping on "zonelim", while I was successfully
> working via another ssh session.
> 
> -- 
> Totus tuus, Glebius.
> GLEBIUS-RIPN GLEB-RIPE
>