From owner-freebsd-arch@FreeBSD.ORG Fri Feb 1 08:23:51 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 97F0718B for ; Fri, 1 Feb 2013 08:23:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B64CD2A1 for ; Fri, 1 Feb 2013 08:23:50 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA16914; Fri, 01 Feb 2013 10:23:48 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U1BuV-0000kk-SE; Fri, 01 Feb 2013 10:23:48 +0200 Message-ID: <510B7B92.4030804@FreeBSD.org> Date: Fri, 01 Feb 2013 10:23:46 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: axe vm.max_wired References: <861umkurt8.fsf@ds4.des.no> <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> In-Reply-To: <20130131091853.GI2522@kib.kiev.ua> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 08:23:51 -0000 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), which >>> specifies number of _pages_ that can be wired system wide (by both kernel 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. >> > > I dislike your proposal. > > The limit is useful to prevent the system from entering live-lock. Well, I definitely agree that we should prevent all of memory from becoming wired. And I myself don't like full axing of vm.max_wired :-) But I do not fully agree with your logic here. Completely prohibiting any page wiring in userland would achieve the goal too, but that doesn't mean that that would be useful. > ZFS-using machines should be tuned. I would like them to be auto-tuned. > 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. > > E.g., could ZFS make an impression that zfs-cached pages are cached, to VM ? I would love to have ZFS ARC implemented differently. 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)... So, meanwhile, I object to your objection :-) You didn't explain why vm.max_wired should be 1/3 of v_page_count by default. 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 kernel and 1% are wired by userland. So, I still think that vm.max_wired as it is used now is too arbitrary and too indiscriminate to be useful. There are other tools to limit page wiring by userland e.g. memlocked limit. 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. -- Andriy Gapon