Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4665297pxu; Wed, 21 Oct 2020 02:02:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxNYi2uRDB9OoTjNZY0/FgXkySWrpc8Dpwdc7kgFX9PLoW1gE7Jllt6NHTQYc9BlGZIzSZ6 X-Received: by 2002:a17:906:5841:: with SMTP id h1mr2414449ejs.342.1603270954536; Wed, 21 Oct 2020 02:02:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603270954; cv=none; d=google.com; s=arc-20160816; b=mGfkmdye6RSPSjFbnizD2la0V44JgL8OZBbjlYwlgYsDS1+Tz0por7R8GT/UbW+ztA 8cFwEQkGvE3GeyTpit4RglNK36rnFOZrqzMV3402AGLQfN6RTnFttfl1Var+GTFOGZ78 VxFNcSgiM24Fww7qLRuq5j2aZc76v7XUry1yVgh2IrRBp9BwbMsVW9aZLOxZui9mNNh8 abG6x1oqiwWOLqBwIdLBpyiNxiZ3Cgyri7T35ofR5O8sA3s1wtRdaKPI2cy6UYjC4VJc KWkgtxqILzpZ1NlAnwuyMm0w3lU8EYQiBZX1ftRc3Ey+ux5l2nErXVHuClHXMBxxbJ8m vNTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=SvI9nFVOm89huMNWCRfBwT5OD9WDOvwN3RZaYD6afks=; b=pYW2sJA3A1wwgiQboR1y/E7w7hsQLd8WO8xhhnztINcfIK8IPibBactJRng2eTWlf7 3BSTVI78D82wqM1FxGIv6/fxE8TX55vZ8ZKm+18+ht9Itd30XX53Dk0yoIXglbAeaTmg dBSZQLVkYusfCG7UheylrgxdsWAo5fsDuQ0UONrwn0wFYwVeOoUliglGKnpYHDsMgtGw YESIFzP2lCiPf9nw+RMjiGnpMRz3KAXAWaVUHxsIMuyQsulapuuxhGMeu74r0DqS8Wjf lWTMpf3yisQ5Mk5ROXut30YFh5YLgxUcIvdjNyy7m1X5VEvsYbcn9tBLoiuTuugY9gIW uCVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b="P3N/QKgu"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g8si1033733edj.61.2020.10.21.02.02.11; Wed, 21 Oct 2020 02:02:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b="P3N/QKgu"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2408881AbgJTSAR (ORCPT + 99 others); Tue, 20 Oct 2020 14:00:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44802 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2408870AbgJTSAO (ORCPT ); Tue, 20 Oct 2020 14:00:14 -0400 Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F28E4C0613CE for ; Tue, 20 Oct 2020 11:00:12 -0700 (PDT) Received: by mail-qk1-x743.google.com with SMTP id r7so2376075qkf.3 for ; Tue, 20 Oct 2020 11:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=SvI9nFVOm89huMNWCRfBwT5OD9WDOvwN3RZaYD6afks=; b=P3N/QKgurREQ+ofcDVlF/8l+2DCDJjzx0/IdzkZzogfwF2BTLRCtlwVtyrrOif6nEe 3xUGE6lSdiufsOrH4IkLoGN7bXqrgwXle4cC+1QsVJI/0Ye+v3mYp8dAv3SjvcAt9jzM sFmisp2CGKNSVes8HdBPouJRXcKeeRQSjOdvbOxudJdk3lzDPPvh5lXFiYTu9X+Kggk4 qcfH6ELidHELA0eKKNNR9mVZ0umexKv/my+a3dyaR71KQrUEO/IJTRRahyIJFd6izQO9 fo5ztebX0HS+B3K47q9PKApNvl3R52BYnhMQfFqC6olR238Sgozi48l+jmJoJ5vdFFzx nDhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=SvI9nFVOm89huMNWCRfBwT5OD9WDOvwN3RZaYD6afks=; b=Kb7RiZjbelJw4Gnl/csUCIWGlElalURf9WFWaoahtcZRYW02nC185TiIBTkpfWOZ9M ix6RNMyXrY6Kc0JbOdTUnjX2QPqdtyLGd9JbCEKSYrkTNDLrlFNBb4ywL+9ijJy2IeBA HIcGtIOLLPX/ZLvAL218PjKygXvRwTWjoFPS9V6G9ggyX+nEgHCtxCXT/bl4jI/Hs0kd Kt2Is8HifUUPEwrOt3vN06+WkZqiPr1UkOcDK3s+wgk6F4mfUvjqY+lvSyBRSMzUx+MA 2YU3VBdJo9HIYjh/2JTki7wkxRERXq/nYSWby/y2f4D8NEI5C9hzNXwZzyLGhxi0zX+K aM+g== X-Gm-Message-State: AOAM530i1BZHQrrlyGaNrqvDhxY9+vlO4iP5vGfPwVxXcg87NA3htWWQ oVMMGxrhPtc00bHf78B3t7FFNA== X-Received: by 2002:a37:a74e:: with SMTP id q75mr2003716qke.277.1603216811818; Tue, 20 Oct 2020 11:00:11 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:c52c]) by smtp.gmail.com with ESMTPSA id j9sm1046697qtk.89.2020.10.20.11.00.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2020 11:00:10 -0700 (PDT) From: Johannes Weiner To: Andrew Morton Cc: Mel Gorman , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: [PATCH] mm: don't wake kswapd prematurely when watermark boosting is disabled Date: Tue, 20 Oct 2020 13:58:33 -0400 Message-Id: <20201020175833.397286-1-hannes@cmpxchg.org> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2-node NUMA hosts we see bursts of kswapd reclaim and subsequent pressure spikes and stalls from cache refaults while there is plenty of free memory in the system. Usually, kswapd is woken up when all eligible nodes in an allocation are full. But the code related to watermark boosting can wake kswapd on one full node while the other one is mostly empty. This may be justified to fight fragmentation, but is currently unconditionally done whether watermark boosting is occurring or not. In our case, many of our workloads' throughput scales with available memory, and pure utilization is a more tangible concern than trends around longer-term fragmentation. As a result we generally disable watermark boosting. Wake kswapd only woken when watermark boosting is requested. Signed-off-by: Johannes Weiner --- mm/page_alloc.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index e74ca22baaa1..4f9d9f7e910c 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2470,12 +2470,12 @@ static bool can_steal_fallback(unsigned int order, int start_mt) return false; } -static inline void boost_watermark(struct zone *zone) +static inline bool boost_watermark(struct zone *zone) { unsigned long max_boost; if (!watermark_boost_factor) - return; + return false; /* * Don't bother in zones that are unlikely to produce results. * On small machines, including kdump capture kernels running @@ -2483,7 +2483,7 @@ static inline void boost_watermark(struct zone *zone) * memory situation immediately. */ if ((pageblock_nr_pages * 4) > zone_managed_pages(zone)) - return; + return false; max_boost = mult_frac(zone->_watermark[WMARK_HIGH], watermark_boost_factor, 10000); @@ -2497,12 +2497,14 @@ static inline void boost_watermark(struct zone *zone) * boosted watermark resulting in a hang. */ if (!max_boost) - return; + return false; max_boost = max(pageblock_nr_pages, max_boost); zone->watermark_boost = min(zone->watermark_boost + pageblock_nr_pages, max_boost); + + return true; } /* @@ -2540,8 +2542,7 @@ static void steal_suitable_fallback(struct zone *zone, struct page *page, * likelihood of future fallbacks. Wake kswapd now as the node * may be balanced overall and kswapd will not wake naturally. */ - boost_watermark(zone); - if (alloc_flags & ALLOC_KSWAPD) + if (boost_watermark(zone) && (alloc_flags & ALLOC_KSWAPD)) set_bit(ZONE_BOOSTED_WATERMARK, &zone->flags); /* We are not allowed to try stealing from the whole block */ -- 2.28.0