From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 478CFC4338F for ; Tue, 10 Aug 2021 15:27:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B6DCF60FDA for ; Tue, 10 Aug 2021 15:27:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B6DCF60FDA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 3F9BF6B007B; Tue, 10 Aug 2021 11:27:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 383186B007D; Tue, 10 Aug 2021 11:27:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 224278D0001; Tue, 10 Aug 2021 11:27:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0175.hostedemail.com [216.40.44.175]) by kanga.kvack.org (Postfix) with ESMTP id 0384C6B007B for ; Tue, 10 Aug 2021 11:27:18 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9F87422BF7 for ; Tue, 10 Aug 2021 15:27:18 +0000 (UTC) X-FDA: 78459549756.07.F6A2E1B Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) by imf08.hostedemail.com (Postfix) with ESMTP id 0324B300271A for ; Tue, 10 Aug 2021 15:27:17 +0000 (UTC) Received: by mail-qk1-f172.google.com with SMTP id a19so22772560qkg.2 for ; Tue, 10 Aug 2021 08:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=i/IO9oWNb+i2H/cOJnKsi5t0uzz0lcp3OlV5Jwlr/e0=; b=jh7k7d+rNKkrGDbIfDRpAEZb0pVUBzH1X4uupkMqmO6ZiVpBDlXH39QrJLRXgGeurH PREcp1yE/NqtCAkpETQltOxYcblwSY0BGX5y7TxycLjGE/kHPAETej7aQrGF5cCYpqZ1 qWBpTOgKkvKM7d5T1jm7AoJWyJhPoCvUO0TWGSpWiUO/buLXdD/0gnCjARxcjEJN0dqW Mv6ZKbOlIv6UZZO3INwr5cEPDX6G52ADNWgyFEDy4lfIi+bluzAsvjnajBfnNaPmFtkE Fa7Sl1WYS88fyUHXcI7vP4OuhinwhD0XxG1UnfilomcYVmMPXyXcSVGYfhAFiAirEsBb Hwhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=i/IO9oWNb+i2H/cOJnKsi5t0uzz0lcp3OlV5Jwlr/e0=; b=dk/Am/vFATvzObjGlw2vz/GsQoOYBYhUxZnBWH2zR8y+9fGUEHRgDDGN0Pq6m/77jM bnr0WPMtHHm/LPdYvL8vN36kg5v3oL2D7ejN5ijlndOXvE/+HsgKs0L3dkzYW7ZsBtcK +KVaB9ypBqonxgkrKn9TrHhN7L/U7+7Z6b0HdYsaDP3IQr27oafItxQcryH3aGIQqtiS kw4JREhYIQGrCNHh9sez+Ui8OfpTQ82AAPKST8j2Q3itXooshzj9NU8CsVGxCEuWbOU9 IijbfQXTmIRd6/Ce/ojswPw6GvR5qN9eQsrhhYaeV7Z1X7in3Ot9NR1qN5ZfhTJUdUmo Cxkg== X-Gm-Message-State: AOAM532VaTT4sc+K01Y/WhaEwVsHzd3vft5/wPnvmFKMpnwWObapoYqj q3x3tqUuQB13Mx6Bb5nQTCGGzQ== X-Google-Smtp-Source: ABdhPJyoKzeNHUGRc6Y0Fqw2m7K28MQLpkXHJysKiWIuwSbR09ZOTlQwsRsHEPw4UAclJ4vMyIQFBw== X-Received: by 2002:a37:9401:: with SMTP id w1mr28916847qkd.166.1628609237211; Tue, 10 Aug 2021 08:27:17 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:6a88]) by smtp.gmail.com with ESMTPSA id bm7sm10611557qkb.79.2021.08.10.08.27.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Aug 2021 08:27:16 -0700 (PDT) Date: Tue, 10 Aug 2021 11:27:15 -0400 From: Johannes Weiner To: Nico Pache Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, aquini@redhat.com, shakeelb@google.com, llong@redhat.com, mhocko@suse.com, hakavlad@inbox.lv Subject: Re: [PATCH v3] vm_swappiness=0 should still try to avoid swapping anon memory Message-ID: References: <20210809223740.59009-1-npache@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210809223740.59009-1-npache@redhat.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 0324B300271A Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=jh7k7d+r; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf08.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.172 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org X-Stat-Signature: zgktzse9f36kqaoe3e869ze86qqhpp9a X-HE-Tag: 1628609237-991466 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello Nico, On Mon, Aug 09, 2021 at 06:37:40PM -0400, Nico Pache wrote: > Since commit 170b04b7ae49 ("mm/workingset: prepare the workingset detection > infrastructure for anon LRU") and commit b91ac374346b ("mm: vmscan: enforce > inactive:active ratio at the reclaim root") swappiness can start prematurely Could clarify what you mean by "prematurely"? The new balancing algorithm targets the lowest amount of overall paging IO performed across the anon and file sets. It doesn't swap unless it has an indication that a couple of swap writes are outweighed by a reduction of reads on the cache side. Is this not working for you? > swapping anon memory. This is due to the assumption that refaulting anon should > always allow the shrinker to target anon memory. This doesn't sound right. Did you mean "refaulting file"? > Add a check for swappiness being >0 before indiscriminately > targeting Anon. > Before these commits when a user had swappiness=0 anon memory would > rarely get swapped; this behavior has remained constant sense > RHEL5. This commit keeps that behavior intact and prevents the new > workingset refaulting from challenging the anon memory when > swappiness=0. I'm wondering how you're getting anon scans with swappiness=0. If you look at get_scan_count(), SCAN_FRACT with swappines=0 should always result in ap = fraction[0] = 0, which never yields any anon scan targets. So I'm thinking you're running into sc->file_is_tiny situations, meaning remaining file pages alone are not enough to restore watermarks anymore. Is that possible? In that case, anon scanning is forced, and always has been. But the difference is that before the above-mentioned patches, we'd usually force scan just the smaller inactive list, whereas now we disable active list protection due to swapins and target the entire anon set. I suppose you'd prefer we go back to that, so that more pressure remains proportionally on the file set, and just enough anon to get above the watermarks again. One complication I could see with that is that we no longer start anon pages on the active list like we used to. We used to say active until proven otherwise; now it's inactive until proven otherwise. It's possible for the inactive list to contain a much bigger share of the total anon set now than before, in which case your patch wouldn't have the desired effect of targetting just a small amount of anon pages to get over the watermark hump. We may need a get_scan_count() solution after all, and I agree with previous reviews that this is the better location for such an issue... One thing I think we should do - whether we need more on top or not - is allowing file reclaim to continue when sc->file_is_tiny. Yes, we also need anon to meet the watermarks, but it's not clear why we should stop scanning file pages altogether: it's possible they get us there 99% of the way, and somebody clearly wanted us to swap as little as possible to end up in a situation like that, so: diff --git a/mm/vmscan.c b/mm/vmscan.c index eeab6611993c..90dac3dc9903 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2477,7 +2477,7 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, * If the system is almost out of file pages, force-scan anon. */ if (sc->file_is_tiny) { - scan_balance = SCAN_ANON; + scan_balance = SCAN_EQUAL; goto out; }