From owner-svn-src-all@FreeBSD.ORG Mon Mar 30 13:30:54 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAA2FE8D; Mon, 30 Mar 2015 13:30:54 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5861C1; Mon, 30 Mar 2015 13:30:54 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.9/8.14.9) with ESMTP id t2UDUsZc095199; Mon, 30 Mar 2015 13:30:54 GMT (envelope-from mav@FreeBSD.org) Received: (from mav@localhost) by svn.freebsd.org (8.14.9/8.14.9/Submit) id t2UDUsih095198; Mon, 30 Mar 2015 13:30:54 GMT (envelope-from mav@FreeBSD.org) Message-Id: <201503301330.t2UDUsih095198@svn.freebsd.org> X-Authentication-Warning: svn.freebsd.org: mav set sender to mav@FreeBSD.org using -f From: Alexander Motin Date: Mon, 30 Mar 2015 13:30:54 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r280850 - head/sys/kern X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 13:30:55 -0000 Author: mav Date: Mon Mar 30 13:30:53 2015 New Revision: 280850 URL: https://svnweb.freebsd.org/changeset/base/280850 Log: Periodically wake up threads waiting for vmem(9) resources, so they could ask for resource reclamation again. This is kind of dirty hack, but as last resort this is better then stuck indefinitely because of KVA fragmentation, waiting until some random event free something sufficient. OpenSolaris also has this hack in its vmem(9). MFC after: 2 weeks Modified: head/sys/kern/subr_vmem.c Modified: head/sys/kern/subr_vmem.c ============================================================================== --- head/sys/kern/subr_vmem.c Mon Mar 30 13:30:15 2015 (r280849) +++ head/sys/kern/subr_vmem.c Mon Mar 30 13:30:53 2015 (r280850) @@ -747,6 +747,12 @@ vmem_periodic(void *unused, int pending) /* Grow in powers of two. Shrink less aggressively. */ if (desired >= current * 2 || desired * 4 <= current) vmem_rehash(vm, desired); + + /* + * Periodically wake up threads waiting for resources, + * so they could ask for reclamation again. + */ + VMEM_CONDVAR_BROADCAST(vm); } mtx_unlock(&vmem_list_lock);