From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 7 09:44:29 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B28D34C5 for ; Tue, 7 Jan 2014 09:44:29 +0000 (UTC) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4806713D7 for ; Tue, 7 Jan 2014 09:44:28 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id e51so7158355eek.27 for ; Tue, 07 Jan 2014 01:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tDXf+ez4FONTJwRdryZbJjtIWhjjGIwDq+GRP5TDMxo=; b=nrOK9SItZaHCu2Rp881VfAHdtrZMnFUhecbAmI/5Nxdc11Yv+2t1g2zWPR+jO0X994 UdEPNtjJh2pnLxPwxZGtCy5T4wAE/7mt2AzcCCYlfrNfCxn9Iwy6X+ecJG4xM/GhKUdQ mZE1Hskvtpp47JDL1KRsoxxXhczjA/e7egktvILI5mNeD+WEpI1NXqqWmQJ1AEKtEKtw rhBIWazw0gMob8tIrvBh03DpM5lIShO8lo4IbC+66UHvj0pn0vP6AzQ/MgeuOPA3G4Xg 4SzT5+Cn2zalyHHqqm+Ao0+0MYC/LOe8IzfzC8U30g75jlnrUdxjpEfToAKlYjGUgba2 znjQ== X-Received: by 10.14.172.130 with SMTP id t2mr20083620eel.68.1389087826305; Tue, 07 Jan 2014 01:43:46 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id h3sm178380265eem.15.2014.01.07.01.43.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jan 2014 01:43:45 -0800 (PST) Sender: Alexander Motin Message-ID: <52CBCC4F.8020900@FreeBSD.org> Date: Tue, 07 Jan 2014 11:43:43 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: UMA caches draining References: <52CB4F7D.2080909@FreeBSD.org> <20140107054825.GI59496@kib.kiev.ua> In-Reply-To: <20140107054825.GI59496@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 09:44:29 -0000 On 07.01.2014 07:48, Konstantin Belousov wrote: > On Tue, Jan 07, 2014 at 02:51:09AM +0200, Alexander Motin wrote: >> I have some questions about memory allocation. At this moment our UMA >> never returns freed memory back to the system until it is explicitly >> asked by pageout daemon via uma_reclaim() call, that happens only when >> system is quite low on memory. How does that coexist with buffer cache >> and other consumers? Will, for example, buffer cache allocate buffers >> and be functional when most of system's memory uselessly consumed by UMA >> caches? Is there some design how that supposed to work? > Allocation of the pages which consitute a new buffer creates the pressure > and causes pagedaemon wakeup if amount of free pages is too low. Look > at the vm_page_grab() call in allocbuf(). Also note that buffer cache > is not shrinked in response to the low memory events, and buffers pages > are excluded from the page daemon scans since pages are wired. Thanks. I indeed can't see respective vm_lowmem handler. But how does it adapt then? It should have some sort of back pressure. And since it can't know about UMA internals, it should probably just see that system is getting low on physical memory. Won't it shrink itself first in such case before pagedaemon start its reclaimage? When vm_lowmem condition finally fire, it will purge different data from different subsystems, potentially still usable. UMA caches though have no valid data, only an allocation optimization. Shouldn't they be freed first somehow, at least an unused part, as in my patch? Also I guess having more really free memory should make M_NOWAIT allocations to fail less often. >> I've made an experimental patch for UMA >> (http://people.freebsd.org/~mav/drain_unused.patch) to make it every 20 >> seconds return back to the system cached memory, unused for the last 20 >> seconds. Algorithm is quite simple and patch seems like working, but I >> am not sure whether I am approaching problem from the right side. Any >> thoughts? -- Alexander Motin