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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78A3BC433F5 for ; Wed, 20 Apr 2022 14:01:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D16BD6B0071; Wed, 20 Apr 2022 10:01:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CC6916B0072; Wed, 20 Apr 2022 10:01:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B40376B0074; Wed, 20 Apr 2022 10:01:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id A094E6B0071 for ; Wed, 20 Apr 2022 10:01:08 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 56E1725CA0 for ; Wed, 20 Apr 2022 14:01:08 +0000 (UTC) X-FDA: 79377419016.22.4F1628F Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf30.hostedemail.com (Postfix) with ESMTP id BEF2380024 for ; Wed, 20 Apr 2022 14:01:04 +0000 (UTC) Received: by mail-qt1-f175.google.com with SMTP id hf18so1019312qtb.0 for ; Wed, 20 Apr 2022 07:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=e1Sscqvoo7rz90w552fG1qluFSOgbb1+p44eFkfXZXw=; b=BkM9SmDrgxYj+HcWafYKsLOSaaQkvO8MYXKQsOg921qCb4v0nRrMUOznRS4a5VLFUx BmxCxhwGnDs978fatHUFHPnnRmuVlZEG4QPYYZhOhUdxamvwrFCjwlrEjVZzHgguwQ7q Is50mVeULvFhzQ6RDedeNeXWimUX2TQE6G9BXWCWhSuaU9okmm7z401UarFu3BI2MPIa 67HKueLQiSlF/pvRGANYugd3ckQ3FFq/8kVzXdQZMRkqsBtP8AX0yFz4QRa+bokecm7J ycWK6Z8HBEH93VeWncKSsfEAJz975O1T/3Y619q5R69A0ccap8aZPTzxRaC8df8PQ5JT bzHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=e1Sscqvoo7rz90w552fG1qluFSOgbb1+p44eFkfXZXw=; b=KhsErxg7N2nTCd+ucEqlf1UuWxt3m5S5DNapDbD24DsSsNh1ijIDOmD7ainrNr1uso LuDy+eLQozNeQtkrWH3HvRbzfaA1h0tGYbLbUz6iDqZGUD8Fjxpz/LQ0Qxuz3zLWZnr4 loDXKK/ruLlQQ77nC8XDCqHdmLp2sadyJncvgWhrhoQNTieQmGUh14iRmo8aWAygW64q 53GYFUocX+NZzEZlaWejCsFVvh9pLcQwuOReCOR9G/zn7jKSpKxOF+Ke3dglcYSw2HDL GzhpoupSeEw4X+g8o/a+F7rUjIH1ru6lagNUeARvsfjrnpfqIqCZ4H1E5ppVkE1ifEe6 Gdsg== X-Gm-Message-State: AOAM53312aNSvi/rb3Fl2uimU3AyaACj1p/QQcmlBUsfS0Nf1zcz4Hnf Ye8ErLdt/LBbWqdWm4uNSHuXCg== X-Google-Smtp-Source: ABdhPJwozpmC0SgweInYjDsRTNf8wKGRtqJ3jxjVI8LofpTyn+G1S8X1pHxVhVdLfumr1ntlcJDH1A== X-Received: by 2002:ac8:7d55:0:b0:2f3:458f:236f with SMTP id h21-20020ac87d55000000b002f3458f236fmr544454qtb.251.1650463265504; Wed, 20 Apr 2022 07:01:05 -0700 (PDT) Received: from localhost (cpe-98-15-154-102.hvc.res.rr.com. [98.15.154.102]) by smtp.gmail.com with ESMTPSA id i18-20020a05620a27d200b0069ecf023d1asm1535936qkp.129.2022.04.20.07.01.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Apr 2022 07:01:05 -0700 (PDT) Date: Wed, 20 Apr 2022 10:01:04 -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: Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=BkM9SmDr; spf=pass (imf30.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.175 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org X-Stat-Signature: 57rrhe78gn5ejiw4wmubpkai4bwhtefh X-Rspamd-Queue-Id: BEF2380024 X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1650463264-434384 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 Tue, Apr 19, 2022 at 07:54:52PM -0400, Nico Pache wrote: > > > On 4/19/22 14:46, Johannes Weiner wrote: > > Hi Nico, > > > > On Tue, Apr 19, 2022 at 02:11:53PM -0400, Nico Pache wrote: > >> I think its is important to note the issue we are seeing has greatly improved > >> since the initial posting. However we have noticed that the issue is still > >> present (and significantly worse) when cgroupV1 is set. > >> > >> We were initially testing with CgroupV1 and later found that the issue was not > >> as bad in CgroupV2 (but was still an noticeable issue). This is also resulting > >> in the splitting of THPs in the host kernel. > > > > When swappiness is 0, cgroup limit reclaim has a fixed SCAN_FILE > > branch, so it shouldn't ever look at anon. I'm assuming you're getting > > global reclaim mixed in. Indeed, I think we can try harder not to swap > > for global reclaim if the user asks for that. > > > > Can you try the below patch? > Sadly this did not fix the V1 case. > > I will have to go back through my notes and over the code again to find what > difference between the two may be causing this issue. Im just starting to focus > on this issue again so my memory needs some refreshing of where I was last at. > > The good news is that with the current state of upstream the issue of swap > storms tearing down THPs seems to be minimized to sane amount with V2. > > My swappiness=0 solution was a minimal approach to regaining the 'avoid swapping > ANON' behavior that was previously there, but as Shakeel pointed out, there may > be something larger at play. So with my patch and swappiness=0 you get excessive swapping on v1 but not on v2? And the patch to avoid DEACTIVATE_ANON fixes it? If you haven't done so, it could be useful to litter shrink_node() and get_scan_count() with trace_printk() to try to make sense of all the decisions that result in it swapping.