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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 A55D1C433E2 for ; Wed, 9 Sep 2020 14:57:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 25A43221EF for ; Wed, 9 Sep 2020 14:57:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="rK7l2L6B" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 25A43221EF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C25F46B0092; Wed, 9 Sep 2020 10:56:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BD3716B0093; Wed, 9 Sep 2020 10:56:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC29A900002; Wed, 9 Sep 2020 10:56:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0152.hostedemail.com [216.40.44.152]) by kanga.kvack.org (Postfix) with ESMTP id 92DD96B0092 for ; Wed, 9 Sep 2020 10:56:58 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 5C8E18248047 for ; Wed, 9 Sep 2020 14:56:58 +0000 (UTC) X-FDA: 77243825316.22.feet37_0b11d35270de Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 2ADF618038E6B for ; Wed, 9 Sep 2020 14:56:58 +0000 (UTC) X-HE-Tag: feet37_0b11d35270de X-Filterd-Recvd-Size: 5052 Received: from mail-qv1-f65.google.com (mail-qv1-f65.google.com [209.85.219.65]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Wed, 9 Sep 2020 14:56:57 +0000 (UTC) Received: by mail-qv1-f65.google.com with SMTP id ef16so1633995qvb.8 for ; Wed, 09 Sep 2020 07:56:57 -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=bAr5DveSt2j6c3Ji2Xpkc3bdZPC9ueaRBHJ+E2ddcbI=; b=rK7l2L6Ba2JCzvKHKa2SJN5u2fNNGcz+xX5FS2fVzlzE39G8QwlSi/S9fdbWoWAxte lRCguLhNf5RYuc9lo5f3oE4Vg8A5hPxuxXsJdR2PC1c2dJzcKAd1xdT+aiqPbVFA2G+c NeXiQNVqrVoihFGdA17ilFkkFzBmfhBUldl7oOfmkoDbT8QG9KI/IuOhFH2SWcD6oNS/ 2g3NyQLRJuVPWj6iFMdDrGMoGxZFkRrepBFTsyENh17ExzZib5VUsUcKLuD/b/oTNTfu Da44+gz/P7k+oDOGzPrpBwvn8NpegUiR/09kLs5DB137Mbv5KbiO+WssE1W8pTn4BGwN DAbg== 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=bAr5DveSt2j6c3Ji2Xpkc3bdZPC9ueaRBHJ+E2ddcbI=; b=BJYtSmh56aezh0qWl6L19H3cKv1Sz+5sdNfB/Ev7vpmWapxokWQNmw4wOYQ6VpHNW5 Zodec46CJMXkbHRsG7cXwN+J8JQBWJiIbnU1vWI09DGtAjIqmpN7vc6hsTWquXeG95wY 8EmiJd2iU0+jIj1U205i3/HDYSqg+TyqU01quyFUT+PaUfLkOvj0HpUWX7ftvh3GeXND LH7vceMUZck5e9j/6sQVM+UaErpG1VIqA++9dbsssr+21HC+GTOADi+9W94XPKd6RN3g bylIjZmkXgshhrpD7SW/GrkWDzMaEf9h/55dp43dLh4wj43LGshcSxI5/7rP+6V+CIWt JwmA== X-Gm-Message-State: AOAM530TEJkKT420vwLYgidJCzmFAUpgT7JaJBmWKvW3hB/QIKjl6eOo LqGm/nvjrFALXbizSiMscbLEwA== X-Google-Smtp-Source: ABdhPJyHGx6zvZoCwcK+52bMv7ajUNNqnFSrgAK1OIrd54oREZtOqFV8s0blObcX2qXQxFQT0Cl0Ew== X-Received: by 2002:a05:6214:bce:: with SMTP id ff14mr4374172qvb.32.1599663416747; Wed, 09 Sep 2020 07:56:56 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:755a]) by smtp.gmail.com with ESMTPSA id q35sm3172982qtd.75.2020.09.09.07.56.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2020 07:56:55 -0700 (PDT) Date: Wed, 9 Sep 2020 10:55:34 -0400 From: Johannes Weiner To: Roman Gushchin Cc: Andrew Morton , linux-mm@kvack.org, =Shakeel Butt , Michal Hocko , kernel-team@fb.com, linux-kernel@vger.kernel.org, Michal Hocko Subject: Re: [PATCH] mm: workingset: ignore slab memory size when calculating shadows pressure Message-ID: <20200909145534.GA100698@cmpxchg.org> References: <20200903230055.1245058-1-guro@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200903230055.1245058-1-guro@fb.com> X-Rspamd-Queue-Id: 2ADF618038E6B X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 Thu, Sep 03, 2020 at 04:00:55PM -0700, Roman Gushchin wrote: > In the memcg case count_shadow_nodes() sums the number of pages in lru > lists and the amount of slab memory (reclaimable and non-reclaimable) > as a baseline for the allowed number of shadow entries. > > It seems to be a good analogy for the !memcg case, where > node_present_pages() is used. However, it's not quite true, as there > two problems: > > 1) Due to slab reparenting introduced by commit fb2f2b0adb98 ("mm: > memcg/slab: reparent memcg kmem_caches on cgroup removal") local > per-lruvec slab counters might be inaccurate on non-leaf levels. > It's the only place where local slab counters are used. Hm, that sounds like a bug tbh. We're reparenting the kmem caches and the individual objects on the list_lru when a cgroup is removed - shouldn't we also reparent the corresponding memory counters? > 2) Shadow nodes by themselves are backed by slabs. So there is a loop > dependency: the more shadow entries are there, the less pressure the > kernel applies to reclaim them. This effect is negligible in practice. The permitted shadow nodes are a tiny percentage of memory consumed by the cgroup. If shadow nodes make up a significant part of the cgroup's footprint, or are the only thing left, they will be pushed out fast. The formula is max_nodes = total_pages >> 3, and one page can hold 28 nodes. So if the cgroup holds nothing but 262,144 pages (1G) of shadow nodes, the shrinker target is 32,768 nodes, which is 32,768 pages (128M) in the worst packing case and 1,170 pages (4M) at best. However, if you don't take slab into account here, it can evict shadow entries with undue aggression when they are needed the most. If, say, the inode or dentry cache explode temporarily and displace the page cache, it would be a big problem to drop the cache's non-resident info at the same time! This is when it's at its most important. Let's drop this patch, please.