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=-2.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 D6469ECE588 for ; Tue, 15 Oct 2019 14:31:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7BC68217D6 for ; Tue, 15 Oct 2019 14:31:48 +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="tV6fx4WF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7BC68217D6 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 111898E0005; Tue, 15 Oct 2019 10:31:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B7848E0001; Tue, 15 Oct 2019 10:31:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF2518E0005; Tue, 15 Oct 2019 10:31:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0122.hostedemail.com [216.40.44.122]) by kanga.kvack.org (Postfix) with ESMTP id CF2448E0001 for ; Tue, 15 Oct 2019 10:31:47 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 674AC181B9DBA for ; Tue, 15 Oct 2019 14:31:47 +0000 (UTC) X-FDA: 76046257854.19.smash40_83f69a1280c02 X-HE-Tag: smash40_83f69a1280c02 X-Filterd-Recvd-Size: 5661 Received: from mail-qk1-f194.google.com (mail-qk1-f194.google.com [209.85.222.194]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Tue, 15 Oct 2019 14:31:46 +0000 (UTC) Received: by mail-qk1-f194.google.com with SMTP id y189so19368126qkc.3 for ; Tue, 15 Oct 2019 07:31:46 -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:user-agent; bh=rLVD7vPJBGWYE3BC+T54ofrBrkXdHmXQZojv0W6wPTA=; b=tV6fx4WFPct3lTQ345Oq5xdMJixBxbdzJ7TXEOs2AxCPbU6ggBQHmQqmttRkGbTrth fKUwwLGnsTfYmRceiI3Xgg90DWKq4uc8M2uCUC0gW7Kszq8+XiEcQm6DORDmpne3DNc3 sP3uuZEW9h1B9OlrpZxPAEvnvNcADrsXQlBARcp4sThPwcJuBQcxX7qj870CDr30s0wy Y/Bru1q+VVfeGEiZXBd0NtokPdennXJiRa6MUbNmTAiBGLUzZbv2mtF4OVrL4AeU9/4O 7yXtd3u+UCcgUo7ynZF+2L510IN+ovY2Y/IJq7wZ2XYC/oEL5iAmc75a89W/b9z4mPS1 UZ6Q== 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:user-agent; bh=rLVD7vPJBGWYE3BC+T54ofrBrkXdHmXQZojv0W6wPTA=; b=rqqiFeUVDPDIEA3g28WKs44vz4zD0Vsf61CxYNu0XScxCb/hQj2I4yHnnRdOhLP5np FrfT7lOfACTGxeMq1UkvQZIfXNOLqNemQ8jhAnO1dl6v/upI1LJ0yNhvyMkaYtDy/bPo uPT9e6oEP6q4jtuH5PeR+lX6mRBhTc5Lk51tuWr1CjoF8OeQqOnz+mIQd0f9xxh3bMhI nynDzmJx7smXD9/Ktfz5cRHOvJ/dPRykZVdfqYIaI1fEn80Nmtc3mrPc1744+dANYhKs XDgRf/wPugCoVVkwcllDg1P0ChwSukVOtAl/AvAZZdETp3kMcXwIWMLPmO51R5lfrBtr QpQQ== X-Gm-Message-State: APjAAAV9d+yq2TmhlzyvJIcGbPlLsRlRnbKTvOGGhsdLhBHgV6cdC0lE 5I1bbF6RUU/P0AkMQ9LSIuRnTg== X-Google-Smtp-Source: APXvYqzunM/QzD2RkF8PdGCuo6II98hv68LXdo5zbgABkad6Kr+uQdefq49as/+MZ8iDH7JqufNQwQ== X-Received: by 2002:ae9:ee06:: with SMTP id i6mr34408845qkg.362.1571149905707; Tue, 15 Oct 2019 07:31:45 -0700 (PDT) Received: from localhost ([2620:10d:c091:500::3:d056]) by smtp.gmail.com with ESMTPSA id o52sm14093380qtf.56.2019.10.15.07.31.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Oct 2019 07:31:44 -0700 (PDT) Date: Tue, 15 Oct 2019 10:31:42 -0400 From: Johannes Weiner To: Michal Hocko Cc: Konstantin Khlebnikov , linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Vladimir Davydov Subject: Re: [PATCH] mm/memcontrol: update lruvec counters in mem_cgroup_move_account Message-ID: <20191015143142.GB139269@cmpxchg.org> References: <157112699975.7360.1062614888388489788.stgit@buzz> <20191015082048.GU317@dhcp22.suse.cz> <3b73e301-ea4a-5edb-9360-2ae9b4ad9f69@yandex-team.ru> <20191015103623.GX317@dhcp22.suse.cz> <31cab57d-6e79-33cb-1a58-99065c6e7b82@yandex-team.ru> <20191015110401.GZ317@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191015110401.GZ317@dhcp22.suse.cz> User-Agent: Mutt/1.12.2 (2019-09-21) 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, Oct 15, 2019 at 01:04:01PM +0200, Michal Hocko wrote: > On Tue 15-10-19 13:49:14, Konstantin Khlebnikov wrote: > > On 15/10/2019 13.36, Michal Hocko wrote: > > > On Tue 15-10-19 11:44:22, Konstantin Khlebnikov wrote: > > > > On 15/10/2019 11.20, Michal Hocko wrote: > > > > > On Tue 15-10-19 11:09:59, Konstantin Khlebnikov wrote: > > > > > > Mapped, dirty and writeback pages are also counted in per-lruvec stats. > > > > > > These counters needs update when page is moved between cgroups. > > > > > > > > > > Please describe the user visible effect. > > > > > > > > Surprisingly I don't see any users at this moment. > > > > So, there is no effect in mainline kernel. > > > > > > Those counters are exported right? Or do we exclude them for v1? > > > > It seems per-lruvec statistics is not exposed anywhere. > > And per-lruvec NR_FILE_MAPPED, NR_FILE_DIRTY, NR_WRITEBACK never had users. > > So why do we have it in the first place? I have to say that counters > as we have them now are really clear as mud. This is really begging for > a clean up. IMO This is going in the right direction. The goal is to have all vmstat items accounted per lruvec - the intersection of the node and the memcg - to further integrate memcg into the traditional VM code and eliminate differences between them. We use the lruvec counters quite extensively in reclaim already, since the lruvec is the primary context for page reclaim. More consumers will follow in pending patches. This patch cleans up some stragglers. The only counters we can't have in the lruvec are the legacy memcg ones that are accounted to the memcg without a node context: MEMCG_RSS, MEMCG_CACHE etc. We should eventually replace them with per-lruvec accounted NR_ANON_PAGES, NR_FILE_PAGES etc - tracked by generic VM code, not inside memcg, further reducing the size of the memory controller. But it'll require some work in the page creation path, as that accounting happens before the memcg commit right now. Then we can get rid of memcg_stat_item and the_memcg_page_state API. And we should be able to do for_each_node() summing of the lruvec counters to produce memory.stat output, and drop memcg->vmstats_local, memcg->vmstats_percpu, memcg->vmstats and memcg->vmevents altogether.