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=-17.7 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 BC766C432BE for ; Sat, 7 Aug 2021 01:37:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3206961186 for ; Sat, 7 Aug 2021 01:37:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3206961186 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 8DF2A8D0001; Fri, 6 Aug 2021 21:37:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 86F4D6B0071; Fri, 6 Aug 2021 21:37:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 754D68D0001; Fri, 6 Aug 2021 21:37:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0055.hostedemail.com [216.40.44.55]) by kanga.kvack.org (Postfix) with ESMTP id 591026B006C for ; Fri, 6 Aug 2021 21:37:20 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D813E1F040 for ; Sat, 7 Aug 2021 01:37:19 +0000 (UTC) X-FDA: 78446571798.17.1AB3FDF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf09.hostedemail.com (Postfix) with ESMTP id 49A3D30600E0 for ; Sat, 7 Aug 2021 01:37:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1628300238; 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=iFTgxVqFqggRkC0Q/K2gaTe9Bsal3TVpnvpZS5yDXGw=; b=I1A/FegfbvGLP7oXFeBTakrkVS+XYcH/NtCk+YkhOb7NgU/q8awVxANjFzfrgZRze6fQ7C wA/5BcbdlK+0WNXDtD0JmWFmXbNobZAVmMJ+ry0xR8Zqh1cQNc6dOs5b0h1EpMoE3b/shg w8JZmylU+SVMZ6Klq/LsUvcOr3j++0I= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-223-dOd5MB73PB2vgzfw_u15vg-1; Fri, 06 Aug 2021 21:37:15 -0400 X-MC-Unique: dOd5MB73PB2vgzfw_u15vg-1 Received: by mail-qv1-f71.google.com with SMTP id v15-20020a0ccd8f0000b0290335f005a486so7573579qvm.22 for ; Fri, 06 Aug 2021 18:37:15 -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-transfer-encoding :content-language; bh=iFTgxVqFqggRkC0Q/K2gaTe9Bsal3TVpnvpZS5yDXGw=; b=SRY/zf7GUguNSfcu36akB+KA0lKnF6r2HfX+eILiIzn6onrABGbFsyn7H10ZDd/CV6 pbvw+Ug6sq8KjydwUygSZaTxbAiJdIRZbPTcTlw2ZTB6PEddLGIqEuaZ5932Pzh5exWn iHys7AQraOX3qxR5t9SOVy/GU7R4GdBxMsOmOiBlhumFobKkzR3JJWoC1hdtlCdKpGTD mUTyifK2vzfUlZvuX6twDffxHqgDwObJg+EPYSBabFgmNgde26Dp7FRzc7YGGv9RXqIS l7+voDmhQcrM8e7OhPoYG90EeEF7TXooc8t4ECF7HU8oIeXiGzEoYiSRWH0kLmybd9Vl 1eow== X-Gm-Message-State: AOAM533YFBTxqmWit5KiIV1qWI23yUznR6vtfI5ec+5CXG7Qr9WrA9ok atIgFudJv6BS1eswBQGjSYD/yCr8I98xrZq3hxqvpLpgB/EwG62beEDf5rgxonx7PsupmKmSkxl Bso3FM4gjQwA= X-Received: by 2002:ac8:58d3:: with SMTP id u19mr11655102qta.306.1628300234985; Fri, 06 Aug 2021 18:37:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyio54RO4lKJEISxBN0ISWIhJ8pL76foRv8ZsxvUzEKBOcdR92OA6qObAVFSkHCxb4tetZaHg== X-Received: by 2002:ac8:58d3:: with SMTP id u19mr11655097qta.306.1628300234809; Fri, 06 Aug 2021 18:37:14 -0700 (PDT) Received: from localhost.localdomain ([2601:184:4180:af10::8eb3]) by smtp.gmail.com with ESMTPSA id n189sm2002998qka.69.2021.08.06.18.37.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Aug 2021 18:37:14 -0700 (PDT) Subject: Re: [PATCH] vm_swappiness=0 should still try to avoid swapping anon memory To: Shakeel Butt Cc: Linux MM , Andrew Morton , LKML , Johannes Weiner , Rafael Aquini , longman@redhat.com References: <20210806231701.106980-1-npache@redhat.com> From: Nico Pache Message-ID: <91605888-e343-2712-c097-bcade4cb389d@redhat.com> Date: Fri, 6 Aug 2021 21:37:13 -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 X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 49A3D30600E0 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="I1A/Fegf"; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf09.hostedemail.com: domain of npache@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=npache@redhat.com X-Stat-Signature: qdeqsspxybug9s6eqrpcjyzqzcqox1qk X-HE-Tag: 1628300239-870978 Content-Transfer-Encoding: quoted-printable 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/6/21 9:00 PM, Shakeel Butt wrote: > On Fri, Aug 6, 2021 at 4:17 PM Nico Pache wrote: >> Since commit b91ac374346b ("mm: vmscan: enforce inactive:active ratio = at the >> reclaim root") swappiness can start prematurely swapping anon memory. >> This is due to the assumption that refaulting anon should always allow >> the shrinker to target anon memory. Add a check for vm_swappiness bein= g >>> 0 before indiscriminately targeting Anon. > Did you actually observe this behavior? Yes, and I've successfully tested this patch. It does solve the issue. > >> Signed-off-by: Nico Pache >> --- >> mm/vmscan.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index 4620df62f0ff..8b932ff72e37 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -2909,8 +2909,8 @@ static void shrink_node(pg_data_t *pgdat, struct= scan_control *sc) >> >> refaults =3D lruvec_page_state(target_lruvec, >> WORKINGSET_ACTIVATE_ANON); >> - if (refaults !=3D target_lruvec->refaults[0] || >> - inactive_is_low(target_lruvec, LRU_INACTIVE_AN= ON)) >> + if (vm_swappiness && (refaults !=3D target_lruvec->ref= aults[0] || >> + inactive_is_low(target_lruvec, LRU_INACTIVE_AN= ON))) > If you are really seeing the said behavior then why will this fix it. > This is just about deactivating active anon LRU. I would rather look > at get_scan_count() to check why swappiness =3D 0 is still letting the > kernel to scan anon LRU. BTW in cgroup v1, the memcg can overwrite > their swappiness which will be preferred over system vm_swappiness. > Did you set system level swappiness or memcg one? This fixes the issue because shrink_list() uses the may_deactivate field = to determine if it should shrink the active list. This is not the only pl= ace that can cause the may_deactivate to deactivate anon, but it is the c= ommon path of kswapd/balance_pgdat. I can look into a get_scan_count() so= lution however this line is the ultimate cause of telling scan controller= to go for anon so i figured this is the best spot ( stop the problem at = the root, not all the way down in the call path). The get_scan_count bala= nce can also be further modified after some shrinking occurs in shrink_lr= uvec.=C2=A0 This is only the system level swappiness. As far as cgroups, I will also = take a look into that to make sure we can generalize the solution for tha= t as well. I dont think it should be too hard.=C2=A0 Thanks for the review! -- Nico >> sc->may_deactivate |=3D DEACTIVATE_ANON; >> else >> sc->may_deactivate &=3D ~DEACTIVATE_ANON; >> -- >> 2.31.1 >>