Date: Tue, 28 Sep 2010 21:13:27 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Andriy Gapon <avg@icyb.net.ua> Cc: fs@freebsd.org Subject: Re: Still getting kmem exhausted panic Message-ID: <20100928181327.GS43070@deviant.kiev.zoral.com.ua> In-Reply-To: <4CA22337.2010900@icyb.net.ua> References: <4CA1D06C.9050305@digiware.nl> <20100928115047.GA62142__15392.0458550148$1285675457$gmane$org@icarus.home.lan> <4CA1DDE9.8090107@icyb.net.ua> <20100928132355.GA63149@icarus.home.lan> <4CA1EF69.4040402@icyb.net.ua> <FE116FEC-714D-4BF5-86D8-E29BFA713C69@wanderview.com> <4CA21809.7090504@icyb.net.ua> <71D54408-4B97-4F7A-BD83-692D8D23461A@wanderview.com> <4CA22337.2010900@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--v6YRErhBvjoBjrPV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Sep 28, 2010 at 08:17:43PM +0300, Andriy Gapon wrote: > ARC is a ZFS private cache. > ZFS doesn't use unified buffer/page cache. > So ARC is not directly affected by pagedaemon. > But this is not exactly VFS layer thing. As a pure speculation, unbacked by any code reasing or understanding of the principles. Can ARC be changed to use some custom vm pager instead of managing memory on its own. As I understand it, ARC uses wired kernel mappings right now. If it starts using managed pages backed by a new pager, then pagedaemon might take actual decisions on the cache shrink by putting and reclaiming pages. Does ARC has some `active' count for the caching unit ? It might be translated to the active count for the page etc. Did I said that this is Pure Speculation ? Seems so, right at the beginning. --v6YRErhBvjoBjrPV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkyiMEcACgkQC3+MBN1Mb4iyIwCghq2eRbNL1kxbdsWjRcijVT3e WH4An0aCYQpyzr3sawdW5TTcA6Lzjtpc =wO8m -----END PGP SIGNATURE----- --v6YRErhBvjoBjrPV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100928181327.GS43070>