Date: Sat, 2 Feb 2013 18:25:09 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: axe vm.max_wired Message-ID: <20130202162509.GZ2522@kib.kiev.ua> In-Reply-To: <510B7B92.4030804@FreeBSD.org> References: <CAF6rxgmDW21aPJ5Mp6Tbk1z02ivw4UPhSaNEX%2BWiu7O0v13skA@mail.gmail.com> <20120517055425.GA802@infradead.org> <4FC762DD.90101@FreeBSD.org> <4FC81D9C.2080801@FreeBSD.org> <4FC8E29F.2010806@shatow.net> <4FC95A10.7000806@freebsd.org> <4FC9F94B.8060708@FreeBSD.org> <51098977.4000603@FreeBSD.org> <20130131091853.GI2522@kib.kiev.ua> <510B7B92.4030804@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--1HZcmCvxmsp4ai32 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 01, 2013 at 10:23:46AM +0200, Andriy Gapon wrote: > on 31/01/2013 11:18 Konstantin Belousov said the following: > > On Wed, Jan 30, 2013 at 10:58:31PM +0200, Andriy Gapon wrote: > >> on 02/06/2012 14:30 Andriy Gapon said the following: > >>> o There is also vm.max_wired sysctl (with no equivalent tunable), wh= ich > >>> specifies number of _pages_ that can be wired system wide (by both ke= rnel and > >>> userland). But note that the limit applies only to userland requests= , the > >>> kernel is allowed to wire new pages even when the limit is exceeded. = By default > >>> the limit is set to 1/3 of available pages. > >> > >> I would like to propose to axe vm.max_wired limit. > >> It is not good when too many pages are wired, but... > >> > >> This limit is quite arbitrary (why 1/3). > >> It's no good for ZFS systems where e.g. 90% of memory can be normally = wired by > >> ZFS in kernel. > >> > >> So this limit should be either axed or perhaps replaced with some much= higher > >> limit like e.g. v_page_count - 2 * v_free_target or some such number "= close" to > >> v_page_count. > >> > >=20 > > I dislike your proposal. > >=20 > > The limit is useful to prevent the system from entering live-lock. >=20 > Well, I definitely agree that we should prevent all of memory from becomi= ng > wired. And I myself don't like full axing of vm.max_wired :-) >=20 > But I do not fully agree with your logic here. Completely prohibiting an= y page > wiring in userland would achieve the goal too, but that doesn't mean that= that > would be useful. >=20 > > ZFS-using machines should be tuned. >=20 > I would like them to be auto-tuned. >=20 > > Or finally the ZFS caches should > > communicate the fact that the pages used are for caches and provide > > easy way for the VM to request flush. This would be big project indeed. > >=20 > > E.g., could ZFS make an impression that zfs-cached pages are cached, to= VM ? >=20 > I would love to have ZFS ARC implemented differently. ZFS integration with the VM, is, to say it mildly, not good. The fact that ZFS cache (ARC ?) presents the cached pages as wired, makes the VM almost useless for a ZFS machine. Your displeasure and tweaks should be directed to ZFS integration, and not to unbalancing current tuning which is not that bad for ZFS-less boxes. > But I do not expect that to happen soon. > Regarding your question - I do not have an answer. Perhaps let's discuss= how > that could be done (while preserving useful/advanced features of ARC)... >=20 > So, meanwhile, I object to your objection :-) > You didn't explain why vm.max_wired should be 1/3 of v_page_count by defa= ult. > You didn't explain how a situation where, say, 80% of pages are wired by = kernel > is radically better than a situation where 80% of pages are wired by kern= el and > 1% are wired by userland. >=20 > So, I still think that vm.max_wired as it is used now is too arbitrary an= d too > indiscriminate to be useful. It is sized well to the default size of the buffer map, which takes 10% of the physical RAM of the machine. Since buffers wiring the pages, be it VMIO or malloc buffer, this leaves 20% for other things, like mbufs, page tables and user wires. >=20 > There are other tools to limit page wiring by userland e.g. memlocked lim= it. The memlock limit is per-process. It is completely useless as the safety measure. >=20 > But, as I've said in the original email, I can agree with vm.max_wired > usefulness if it is set to something more reasonable by default. > IMO, it should not be a fixed percentage of available memory, it should be > derived from other VM thresholds related to paging. Might be. Please provide a suggestion or better, a change. --1HZcmCvxmsp4ai32 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRDT3kAAoJEJDCuSvBvK1BE8oP/RgdrDpRyGLUcSwbl3Htn4+E 3rR++k82lp2PA0Dn6XkNOLKMK6jPg0ytuu46gkl2t6jCSwuA0cvUOgK5p56Pm763 XYQ+ptV9G8wg4QaZc4yFzhEDEbqEPeO253qmpNhh59T680Ylxho9ZDRcvVQEyHtt /J9VpjfwZV4wUdwbR8dPz0zRt+OaOJuie1e5HlAuhBfele5PoMARkcUFav0i5RZu YfYfUkj9VHL9eLCticdvAezXuLj268fmGRK4pjU2u9Ke1qxLngoe0TRVRV5/2Zgk 7e6f2h5xmbQvdxyAGsLivxtVWqKUgFmu2y8Cl4sUn2i2Jvoqcp5VPtTn1VnfhqQm d7whq6GhQ/fASnHjPMglsn+1YnUxMvXl/v0OfJED4AXuRLxDiZAmSRyiLUhSgXfB YiDWu8A040s3yk8BVJWttows7wzVTGFbi14eXQWbNnQL/3XQpohpQmO6AoVfhxZm 3hMTeDZjn5VwqzkYkp449YPATm0xL6dtd5rMxxX1uxAUOPTfTtA3E/GWd2PlxywA k7DICYTIWsCTaO+3DbmCsb2tKyRopQLD4LEzwa29zOd1mMPHhknCBEevBPaTm7el J7pvo0PyDT4Q7TcN7dWnfhYfV6UhxeHMzvad2U3MNYTlZUlmTrFwroCC4hM3kbuH wvshxawnnOwS+yyct6h4 =Wijp -----END PGP SIGNATURE----- --1HZcmCvxmsp4ai32--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130202162509.GZ2522>