Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp1083762ybf; Thu, 27 Feb 2020 04:47:31 -0800 (PST) X-Google-Smtp-Source: APXvYqzqzwZP4+vujITh597VMsw3JIFJCz0J8nZqchIoabrCCS/7i6I7/nJKbYmc+6T5lWHoKHXs X-Received: by 2002:a54:4816:: with SMTP id j22mr1459773oij.162.1582807650957; Thu, 27 Feb 2020 04:47:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582807650; cv=none; d=google.com; s=arc-20160816; b=c8Fc1ZbOW2Bt/uu/aeXyv2J/wVZE8sTUuhHitEeNYkYIJ+2N+pUCa4PqN7AR7+zejt oDwoDr2QC4iwZun11V2RZYjIM01z5QxJo6577r383An0WdeT20Ptmt8V1DdMRm89HDAb PnqkyUPjvArIEqlVn4bfkrfj4xIPrEWx+d3QxCEl/WM4ktR/eeG/VpksnvGtzFwAvH3T 7ct5JY+deGAolIHF+h2f5Ov5uSOaVC8TOo3unfQ1ihuSGDoUTLmmNj7PFXfLfaRBhJMK DVLPwBPzQd9gSAKJGvidZ8d5ZZXRHRKkk765Lm5pLiJCfuLx4Qdy96pr/QXv71vnemDf 2G8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=WLxOr23M2LVzQj7SGEmn+VRUgkFWr6fL5n2/WQgfv/8=; b=UinMxCSTlpyt9Jrnt9QIHikPb85BqY+kvwnXCxwbL3eTf6M/n7vzNF1xzSDQPU9XbN qRHayZhDVYaKSEOT7FUsDIwEGp7jSA0q7pwQRDtERaz/6B/umkg0o8L8dFINLLeUTM5Q 5LhT7835mGVviJFiosaN60K+/gk54YGfkebO9gPCDO6QblsNC0zB4m9MqNkiEq6A5uVx Oszkg99WyTGiWL2J0CJkU7zwYv1gXS2HRG3xCKNc8EkybLZLdX7IV13UTvz0vjoocoTK t6o2UuWdk4715v+QoMNDyPTfvSLM6cj0Rl0PdO95M0ysXBr9SGC/7svi4+wiKL1I6BTh 4Wtw== ARC-Authentication-Results: i=1; mx.google.com; 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 x23si1248972oie.50.2020.02.27.04.47.18; Thu, 27 Feb 2020 04:47:30 -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; 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 S1729067AbgB0MqB (ORCPT + 99 others); Thu, 27 Feb 2020 07:46:01 -0500 Received: from mx2.suse.de ([195.135.220.15]:56478 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728964AbgB0MqA (ORCPT ); Thu, 27 Feb 2020 07:46:00 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C92E2AC44; Thu, 27 Feb 2020 12:45:58 +0000 (UTC) Subject: Re: [PATCH] mm/page_alloc: increase default min_free_kbytes bound To: John Hubbard , Joel Savitz , linux-kernel@vger.kernel.org Cc: Andrew Morton , Rafael Aquini , linux-mm@kvack.org References: <20200220150103.5183-1-jsavitz@redhat.com> <4778f04b-7ff0-0648-1ff9-dd02c79f45ea@nvidia.com> From: Vlastimil Babka Message-ID: Date: Thu, 27 Feb 2020 13:45:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <4778f04b-7ff0-0648-1ff9-dd02c79f45ea@nvidia.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/21/20 2:53 AM, John Hubbard wrote: > On 2/20/20 7:01 AM, Joel Savitz wrote: >> >> Currently, the vm.min_free_kbytes sysctl value is capped at a hardcoded >> 64M in init_per_zone_wmark_min (unless it is overridden by khugepaged >> initialization). >> >> This value has not been modified since 2005, and enterprise-grade >> systems now frequently have hundreds of GB of RAM and multiple 10, 40, >> or even 100 GB NICs. We have seen page allocation failures on heavily >> loaded systems related to NIC drivers. These issues were resolved by an >> increase to vm.min_free_kbytes. >> >> This patch increases the hardcoded value by a factor of 4 as a temporary >> solution. >> >> Further work to make the calculation of vm.min_free_kbytes more >> consistent throughout the kernel would be desirable. >> >> As an example of the inconsistency of the current method, this value is >> recalculated by init_per_zone_wmark_min() in the case of memory hotplug >> which will override the value set by set_recommended_min_free_kbytes() >> called during khugepaged initialization even if khugepaged remains >> enabled, however an on/off toggle of khugepaged will then recalculate >> and set the value via set_recommended_min_free_kbytes(). >> >> Signed-off-by: Joel Savitz >> --- >> mm/page_alloc.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index 3c4eb750a199..32cbfb13e958 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -7867,8 +7867,8 @@ int __meminit init_per_zone_wmark_min(void) >> 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; >> + if (min_free_kbytes > 262144) >> + min_free_kbytes = 262144; > > > Would it be any better to at least use symbols, instead of numbers, in the > routine? Like this: +1 Thanks