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 <[EMAIL PROTECTED]> 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 > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
