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=-13.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable 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 32B3EC432BE for ; Tue, 10 Aug 2021 19:24:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ACC1260FDA for ; Tue, 10 Aug 2021 19:24:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org ACC1260FDA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 10C396B0072; Tue, 10 Aug 2021 15:24:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0BBE08D0001; Tue, 10 Aug 2021 15:24:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EEF076B0074; Tue, 10 Aug 2021 15:24:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0205.hostedemail.com [216.40.44.205]) by kanga.kvack.org (Postfix) with ESMTP id D62356B0072 for ; Tue, 10 Aug 2021 15:24:51 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8CA1F2310B for ; Tue, 10 Aug 2021 19:24:51 +0000 (UTC) X-FDA: 78460148382.34.2FB68DF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf21.hostedemail.com (Postfix) with ESMTP id F0FFBD0242AF for ; Tue, 10 Aug 2021 19:24:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1628623490; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xMD9b/hP3x1fPYrhGrNkImlTo/6vlXT13PvAhB2yObQ=; b=gEmifnQMxZqBhPzxe/0O4hy+OiavI5f5iojNGfcQ7h7DOufa+nJT/WndthiYisqZUSylAY +/R1l16iFzz/R+hQu/3ZJfP35JBz9DjY3GnS/3q+PddDRkZogC5hvH2BE87qJkXqRYuqSi tnM1oyA1cuiGfwdh84jkr2F8374kHFk= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-476-BxwDBep6OOSQzOxBcmvn7A-1; Tue, 10 Aug 2021 15:24:47 -0400 X-MC-Unique: BxwDBep6OOSQzOxBcmvn7A-1 Received: by mail-qk1-f198.google.com with SMTP id b4-20020a3799040000b02903b899a4309cso17658321qke.14 for ; Tue, 10 Aug 2021 12:24:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xMD9b/hP3x1fPYrhGrNkImlTo/6vlXT13PvAhB2yObQ=; b=p8t0DOZn01ZjKGbkAXoTKTaOnUWe1nweU+yrVoaY7l9ZW+ZsCt2SgUYxDVvbhamyzt g3TAuiaRQkf1yML5qA98LfvSkE3bJVU5sIBLdP3Y8Yp2ekCdOov2aDB7NisPrC3E4v/O W4d2zePLWbs+2bA2vnEIcS37DM5Zf/X7Lxmf9KrY2c5U/7rk6sNX7iw4tMB2V1MvW/Mo 5DhQl+TWf/Tq4REcz2J2nouovfNwEysx5APlI1NO7FCF7NUHicPKy8rxknm1r2JWp1hH JpWokXl0Hw7/1euVcRvjpObcGL4KWWvjkK8TSz9WHdOzKscG5vglRynqz0QiFi69lVcC SqkQ== X-Gm-Message-State: AOAM532TKsS1OBctJkHw+JhKcty0HmK4HA4V09CCNu8I64RtmcbWxk/M OPHKu/mlcZOUd2epx6HQ6Amirip4vLrtooO4V3zyK5eMF86YRFNlntZt4lyS0AzguWoCQOhD6GI egT3qJyj9FMU= X-Received: by 2002:a37:5a02:: with SMTP id o2mr30399282qkb.476.1628623486966; Tue, 10 Aug 2021 12:24:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxWL+NFpWrrLCOwbdN9suzlxrWwMNccU+3YN9IA6pcNSTJWP0QMcAx2romXuMH30XZw+2HdaA== X-Received: by 2002:a37:5a02:: with SMTP id o2mr30399257qkb.476.1628623486753; Tue, 10 Aug 2021 12:24:46 -0700 (PDT) Received: from ?IPv6:2601:184:4180:af10::540e? ([2601:184:4180:af10::540e]) by smtp.gmail.com with ESMTPSA id v10sm3168518qkj.104.2021.08.10.12.24.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Aug 2021 12:24:46 -0700 (PDT) Subject: Re: [PATCH v3] vm_swappiness=0 should still try to avoid swapping anon memory To: Johannes Weiner 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 References: <20210809223740.59009-1-npache@redhat.com> From: Nico Pache Message-ID: Date: Tue, 10 Aug 2021 15:24:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: F0FFBD0242AF Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gEmifnQM; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf21.hostedemail.com: domain of npache@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=npache@redhat.com X-Stat-Signature: 4o3g74xyjjgf9w8m1arxsbnbcfnzbxcq X-HE-Tag: 1628623490-766633 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: On 8/10/21 11:27 AM, Johannes Weiner wrote: > 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"? Hi Johannes! The reason I used the words prematurely and indiscriminately when trying to describe the behavior is because AFAICS the swappiness value is not being considered and this isnt a OOM case, so its prematurely going for anon memory. > > 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? Well it is for the most part, but to your point below, the sc->is_file_tiny case can directly bypass the meaning of swappiness and chooses to do whatever it likes. > >> 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"? refaults = lruvec_page_state(target_lruvec, WORKINGSET_ACTIVATE_ANON); if (refaults != target_lruvec->refaults[0] || inactive_is_low(target_lruvec, LRU_INACTIVE_ANON)) sc->may_deactivate |= DEACTIVATE_ANON; Perhaps this is incorrect then? target_lruvec is using refaults[0] which is collected in snapshot_refaults. snapshot_refaults is populating index 0 with the WORKINGSET_ACTIVATE_ANON page state. the refaults variable is doing the same. So I assumed the refaulting ( new refault count != snapshot count) is comparing that of the anon workingset memory, not the refaulting of file cache. > >> 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? Yes DEACTIVATE_ANON is enabling the file_is_tiny case in shrink_node(). That is what im trying to prevent in the swappiness=0 case. > > 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 Well kind of. It used to be that inactive_list_is_low would allow allow for the scanning of anon memory, but I am not removing that case here. Thats why my V3 separated the swappiness check from the inactive_is_low. Furthermore, the active list protection use to only be considered on the file LRU, as seem in ~4.18 inactive_list_is_low. > > 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. Yes I believe this is also makes the problem worst. Im not sure if given the anon memory the same read-once optimization (starts on the inactive list) as file cache is the way to go. > > 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... I cant see why a get_scan_count solution is better then removing the problem where it starts. > > 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; > } I agree, I think allowing it to scan both would be better as well. Cheers! -- Nico