Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp770799ybv; Thu, 20 Feb 2020 07:02:33 -0800 (PST) X-Google-Smtp-Source: APXvYqywstrEZGevJdEYweMlCcp0PfAnPTDtlPk9L6icGVQayYa1kjfncUwOT583U7Qa980OZxOk X-Received: by 2002:a9d:51ca:: with SMTP id d10mr23879178oth.76.1582210953250; Thu, 20 Feb 2020 07:02:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582210953; cv=none; d=google.com; s=arc-20160816; b=P25li1530DFiiKkJzvFXTxDRrUJUqOpeVhOTgmu2PCxnAFolL1GjevndDQGymalzJ7 ImqT+Mrwc0E7ojuxaZxJiF+dADpEU9pGiV+GG0bBBo+nb4uA+rRe4+WCBnzLeNRB+PjQ YPyJEI0mevaZrKQw+8DiObTOuIroBZceOUAIl/SDU1bdpksWVPJxLU+YErrkO3mwh7Ds Ji5q+YTxyfJ4cK/p1lw60sr0WQUkSl/nr1JFfUeT36xoODAYwpUG7UqzYbTpA7ei2JmW Yj010KjKp/rCf/2t+b5pmx1LidHBPMVi2jyYO1YFsWEISxk2DgTq04FCDLLZofmQtxEW Ui3g== 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:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=akPGLEa5++8awpmZaCXevB0Sy30q2hFWMSty4YYV3yA=; b=BdrWn2nv1FwZJwxBmVyZhTnGjcPj9tFFmWyQMCuJ44POVqe2zYyNHjGwiqbORR1uuv GirIoKwVp8lj8BIUdlqrJ5acxJTzB5yFunNYjf6oYxTzujEb0r+1+f4580bMQkChOUAX cIJNncCHmAqnCZwDDiCE++U1tstMHkvfOkpCzDCnUW6mqCbse/QIB2XuSkQf0OV+nxoY z33oy9XljE0MAuVVqF0MDZFWfAxD3jkmHHM6xEBubvL/RwRa2kzuYvGEzCvmV6QDyBrm wJyJKEN2Hk05QjhJbyZT9ozAEsIG6Ri2y3t48s9oDVKYQGFfJy2kOzQkziSgBxlDxnuy knuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HsHPYZzE; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w142si10603490oia.132.2020.02.20.07.02.18; Thu, 20 Feb 2020 07:02:33 -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=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HsHPYZzE; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728529AbgBTPBf (ORCPT + 99 others); Thu, 20 Feb 2020 10:01:35 -0500 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:21700 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728133AbgBTPBf (ORCPT ); Thu, 20 Feb 2020 10:01:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582210894; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=akPGLEa5++8awpmZaCXevB0Sy30q2hFWMSty4YYV3yA=; b=HsHPYZzEw6D5Z9q62uLlAPKXEFdJ5icXZntPhGVEf2TQnrQzWr3XkZnMT7bBmaRoGczJok e55e0bh/Y3LFHp/2u9xuA2evWn7bzcBzZitvYyfozycqaXpMHv6qJ4hY6D3HKjTGKfPeHB osl5gVshiLfcNaK+8NiS85LCuUNO5Uw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-384-2zfB-8laOpmnJ97p9pu7aA-1; Thu, 20 Feb 2020 10:01:29 -0500 X-MC-Unique: 2zfB-8laOpmnJ97p9pu7aA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 32C60800D5E; Thu, 20 Feb 2020 15:01:28 +0000 (UTC) Received: from jsavitz.bos.com (dhcp-17-196.bos.redhat.com [10.18.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id CE08D1001B2C; Thu, 20 Feb 2020 15:01:23 +0000 (UTC) From: Joel Savitz To: linux-kernel@vger.kernel.org Cc: Joel Savitz , Andrew Morton , Rafael Aquini , linux-mm@kvack.org Subject: [PATCH] mm/page_alloc: increase default min_free_kbytes bound Date: Thu, 20 Feb 2020 10:01:03 -0500 Message-Id: <20200220150103.5183-1-jsavitz@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 =3D new_min_free_kbytes; if (min_free_kbytes < 128) min_free_kbytes =3D 128; - if (min_free_kbytes > 65536) - min_free_kbytes =3D 65536; + if (min_free_kbytes > 262144) + min_free_kbytes =3D 262144; } else { pr_warn("min_free_kbytes is not updated to %d because user defined val= ue %d is preferred\n", new_min_free_kbytes, user_min_free_kbytes); --=20 2.23.0