From owner-cvs-src@FreeBSD.ORG Thu Jan 25 17:39:13 2007 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 116E616A408 for ; Thu, 25 Jan 2007 17:39:13 +0000 (UTC) (envelope-from mohan_srinivasan@yahoo.com) Received: from web30809.mail.mud.yahoo.com (web30809.mail.mud.yahoo.com [68.142.200.152]) by mx1.freebsd.org (Postfix) with SMTP id A8C8E13C467 for ; Thu, 25 Jan 2007 17:39:12 +0000 (UTC) (envelope-from mohan_srinivasan@yahoo.com) Received: (qmail 93831 invoked by uid 60001); 25 Jan 2007 17:12:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KdlQvmM7y1i8PgaKPO38dZOPih17hgYqbeR61u8zid1eD2GlVH+Zbm6HVWTamU/+PhNcoENF7Vh11bTUOQodGNvNIkkeGeQEX/fJlRn31PFcLuo8PSlYFGydEWC998yJUf0LMKBV00rwu5ktcGsLne9X4nk1kJ6z4LjIgALzT58= ; Message-ID: <20070125171231.93829.qmail@web30809.mail.mud.yahoo.com> X-YMail-OSG: Dv4vVwsVM1nL218.5zuW9qQMCOkPKchL9d5X3ToO3BvWoqupSvUEZWbkTobr5S1HCCP5_Q22VejEqcr_rer_iLGG2lT4pQ2NVIFro9VipOpchsXHQFdt.5T_byRgIclORA-- Received: from [71.198.5.118] by web30809.mail.mud.yahoo.com via HTTP; Thu, 25 Jan 2007 09:12:31 PST Date: Thu, 25 Jan 2007 09:12:31 -0800 (PST) From: Mohan Srinivasan To: Gleb Smirnoff , Mohan Srinivasan In-Reply-To: <20070125102045.GJ4485@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm uma_core.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 17:39:13 -0000 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 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 >