Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5427877ybl; Tue, 4 Feb 2020 13:55:03 -0800 (PST) X-Google-Smtp-Source: APXvYqwV8E7GgPlfYVA9jEravvsRaNTg24aijQu+7/DGYXYaFun3TzfcV1R44/g4O1E3bSckGV/v X-Received: by 2002:aca:ab53:: with SMTP id u80mr759164oie.94.1580853303255; Tue, 04 Feb 2020 13:55:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580853303; cv=none; d=google.com; s=arc-20160816; b=PZeK4vMw7KICAu75aKXOaoQhqIIldrODLGQkKITwE7dL219C5Hg2hhTz9ClLPYW9AB BllfbvtyT3m/kNfkpRV37idoJRcTvnV9CbpDI7DBPVMM0r7OLhyd/BoGrglG64jNEp9p tXfH5wo1es/8FzcaFhuqenJPSfZG+JTe+BBs4oG5NhZ1c+S6Byq8UgdfnVVlu42Iwd5V daT3FimAuv3j114ieHSXr3GATF0xn9KvQ5VTiiS6kOO8Lg/dlBjwJzeIP6l9BX6pprtI IVd5O1qoE6w9NP9eVOtquyzIvQAbk7e6xPi82o4Ve4wTzbxoEbM3vmsWw5mxOQSK42UK K5DA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=w6OXzP+HHp11meNIJ9sGsy1A1zoYw1xroawhHjswMtk=; b=uzwrzQeNZa6M1tkgXZbtX/bmgnyVe6Gk6+NZAEjaVUx9LxMmYsKPeV7Vea0R6VGQbE Fgxg7jvt2+p5JPFQd6IwH3PegZipoPAoS97dRnSfxpN0z+64DGssxJU7FwuGKFRhWA/i 20eZDzlky5BVbn5ofheLj4vybdmJFuWSmzDVEN5ohEAPrFKjRzl+bXE8wqOk+dXC/EB8 mfos0DBRxt/eqYZ3olguCyJC5EuADIhPsT8hk+pA071kQbex221vICn8RDr67tbVCTLa DDZXBSzqvwHewGhkMVuahlHIPSSJf5vZgd977fsV5rVNvjSG3EFnO1DYA9kkoa5zbhav ET+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=qub5Y+M7; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s15si10391585oih.252.2020.02.04.13.54.51; Tue, 04 Feb 2020 13:55:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=qub5Y+M7; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727619AbgBDVxZ (ORCPT + 99 others); Tue, 4 Feb 2020 16:53:25 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:34514 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727563AbgBDVxZ (ORCPT ); Tue, 4 Feb 2020 16:53:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=w6OXzP+HHp11meNIJ9sGsy1A1zoYw1xroawhHjswMtk=; b=qub5Y+M7Sgeh5dq3fj4fqTp0wS 2CXcyu0en/Webtsc5wa4GheR5icm0dDqQcrUZB3sKHCdaOUprRTFOzcIcMZlLSJl+CQi3ICMrJqHx w+8MXUcwZmTGRj7S4DMk6lwTTxQxmnu5Y1lPcky0FjtScd77LH8mQLCxBURcc2rNOywvAbkaOCL94 +7fmdTQG39YAVsUjwGQyv0JOfB9EMTKmejvt5DlN0Fi2j7aCuOq91CWMS4wekb4VjAzDGABbteRtz Gyp9kt1Ljl/KWsGxvIHOshoJZhfwSGh0p06PlJP/ElwWrMGpFaU8eprbb957DOzV5HSW1ehY3CWat FNK6ZBXg==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1iz68F-0006V2-Ux; Tue, 04 Feb 2020 21:53:19 +0000 Date: Tue, 4 Feb 2020 13:53:19 -0800 From: Matthew Wilcox To: Mike Kravetz Cc: David Rientjes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Song Liu , "Kirill A.Shutemov" , Mel Gorman , Vlastimil Babka , Andrew Morton Subject: Re: [PATCH] mm: always consider THP when adjusting min_free_kbytes Message-ID: <20200204215319.GO8731@bombadil.infradead.org> References: <20200204194156.61672-1-mike.kravetz@oracle.com> <8cc18928-0b52-7c2e-fbc6-5952eb9b06ab@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cc18928-0b52-7c2e-fbc6-5952eb9b06ab@oracle.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 04, 2020 at 01:42:43PM -0800, Mike Kravetz wrote: > On 2/4/20 12:33 PM, David Rientjes wrote: > > On Tue, 4 Feb 2020, Mike Kravetz wrote: > > > > Hmm, if khugepaged_adjust_min_free_kbytes() increases min_free_kbytes for > > thp, then the user has no ability to override this increase by using > > vm.min_free_kbytes? > > > > IIUC, with this change, it looks like memory hotplug events properly > > increase min_free_kbytes for thp optimization but also doesn't respect a > > previous user-defined value? > > Good catch. > > We should only call khugepaged_adjust_min_free_kbytes from the 'true' > block of this if statement in init_per_zone_wmark_min. > > if (new_min_free_kbytes > user_min_free_kbytes) { > min_free_kbytes = new_min_free_kbytes; > if (min_free_kbytes < 128) > min_free_kbytes = 128; > if (min_free_kbytes > 65536) > min_free_kbytes = 65536; > } else { > pr_warn("min_free_kbytes is not updated to %d because user defined value %d is preferred\n", > new_min_free_kbytes, user_min_free_kbytes); > } > > In the existing code, a hotplug event will cause min_free_kbytes to overwrite > the user defined value if the new value is greater. However, you will get > the warning message if the user defined value is greater. I am not sure if > this is the 'desired/expected' behavior? We print a warning if the user value > takes precedence over our calculated value. However, we do not print a message > if we overwrite the user defined value. That doesn't seem right! > > > So it looks like this is fixing an obvious correctness issue but also now > > requires users to rewrite the sysctl if they want to decrease the min > > watermark. > > Moving the call to khugepaged_adjust_min_free_kbytes as described above > would avoid the THP adjustment unless we were going to overwrite the > user defined value. Now, I am not sure overwriting the user defined value > as is done today is actually the correct thing to do. > > Thoughts? > Perhaps we should never overwrite a user defined value? We should certainly warn if we would have adjusted it, had they not changed it! I'm reluctant to suggest we do a more complex adjustment of the value (eg figure out what the adjustment would have been, then apply some fraction of that adjustment to keep the ratios in proportion) because we don't really know why they adjusted it. OTOH, we should adjust it if the user-set min_free_kbytes is now too large for the amount of memory now in the machine.