From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 7 05:48:38 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 E5FDA775; Tue, 7 Jan 2014 05:48:38 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 71AF91317; Tue, 7 Jan 2014 05:48:38 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id s075mQWN061811; Tue, 7 Jan 2014 07:48:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s075mQWN061811 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id s075mPuf061810; Tue, 7 Jan 2014 07:48:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 7 Jan 2014 07:48:25 +0200 From: Konstantin Belousov To: Alexander Motin Subject: Re: UMA caches draining Message-ID: <20140107054825.GI59496@kib.kiev.ua> References: <52CB4F7D.2080909@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7urMzS8W4fOs217t" Content-Disposition: inline In-Reply-To: <52CB4F7D.2080909@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home 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 05:48:39 -0000 --7urMzS8W4fOs217t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 07, 2014 at 02:51:09AM +0200, Alexander Motin wrote: > Hi. >=20 > I have some questions about memory allocation. At this moment our UMA=20 > never returns freed memory back to the system until it is explicitly=20 > asked by pageout daemon via uma_reclaim() call, that happens only when=20 > system is quite low on memory. How does that coexist with buffer cache=20 > and other consumers? Will, for example, buffer cache allocate buffers=20 > and be functional when most of system's memory uselessly consumed by UMA= =20 > 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. >=20 > I've made an experimental patch for UMA=20 > (http://people.freebsd.org/~mav/drain_unused.patch) to make it every 20= =20 > seconds return back to the system cached memory, unused for the last 20= =20 > seconds. Algorithm is quite simple and patch seems like working, but I=20 > am not sure whether I am approaching problem from the right side. Any=20 > thoughts? >=20 > --=20 > Alexander Motin --7urMzS8W4fOs217t Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSy5UoAAoJEJDCuSvBvK1BIwsP/0yzFSF1REoZz7us7XQr2XRQ EriCJDyk4XUCFVCZOYgYAHu+z2iRfQ1NdnYY3FXm3DVNj/DSrPPO9OPJq+YgB/6V eBL1B6haZi3PqdaaRwhyhQaV+LuEZBItyrBbMT0Xfu4Myd5iHHe38AXgwd2+rRqn 9KY0ipdyfQWzp15+hzRmWnPe/7ziR6XjEO6mGkfDNcL0ZgDAUCRqjqJPp7WNSUHG pd3EybTGylLOwubWHhxlpvYqIYP1BXRHbJI23Tmr4gXucsmBglEF5sL6RCxYrHao W1xMbuZxyfnXF6scrSHq0E5/Mq1AS77zMo+joz5YfLNSDn1af8KkIlHvpdLatFMt p4caq4lcOLlYPjZg6O0DTOoOm/bWZ3MMkocY3+phDfz4dg0wlN9Mwi4KMjBPx8nV 7ZqHo9fq+IDAi1/+hmxxZXf2zrs4Z+xN9zwaXfO3yvADmrzkUCykK22Batb+2m4S pB3r2KVeru3sjxTL+QCBNH/PxYqLZKDuO96U3HJgxePsaOG1t+GGTaXWfxcMIH2X hmPJeEPf7HZ2Wl7s1tnotm3SDmY5lH/r3A5za7jQwtAZpm0N3NNZsKmOcS57lllj LlXDcBUtEoy0QEaoj5ZYNwyB8wzdVW8GLeq9tz+2RBFt4Po6gmR0UJKUopo8dBY9 zvgIVtiXfKQyZdSr38Gk =I3c7 -----END PGP SIGNATURE----- --7urMzS8W4fOs217t--