Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5759472ybp; Tue, 15 Oct 2019 04:44:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqzlX/kAykikbIqq/4BMftUNm86m4iaWgMi1gOaWRsYIT9g5+BiLHzol9Y4PagHTmmfg/XXG X-Received: by 2002:a05:6402:21dd:: with SMTP id bi29mr32906668edb.7.1571139849336; Tue, 15 Oct 2019 04:44:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571139849; cv=none; d=google.com; s=arc-20160816; b=E4rd6yeR0WLgh8v8Dw3ofvmdcAAiDf/TGZR+/BzBVO1S1Zl5sSRPIpQPxaVXPDaPIx UNHHwGxnkhzYclyNJbVuZLc3Tj0qklXGmtL0x5szgNka0fnMgd4mvHzu2nSnxOCYcgEH fC9vLc//azGTWs1MzyZj/923mVInk0z3QIUgm30zwIa06YwHyOuXVPM17fvD8xeNSUS7 yk8PysFufyKq5DyV0ImyD7UJT8D7emSyFhygxSEIR4ZYpjT86vGHch8wAix1RtZ7Tv8h K9fEVytgoKXv8RTuYOXPtOy1aF3cuQ2ixwZ2eFEhoiWf/2b5ysQQBap59rS7GUI1O3zb 6+sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=zCpfWs+CrGNGj/5+pczaMGZ846MTmmwzcGstYpHG5hU=; b=IeaPypuTYGJH91/CgiGOW4A23jFqc+TpdfqD2F4WbrZK6MXyK+gNJUXxgbDf01epgi mykczYa73mHTPkui69pKvyVhZDwQQnHvEWP63OLtouOCm+OfsZumaRe5IC3d53szCMGz D3PcsQFEOvUFdky7/SrLvMOP29Q8dK3GWpdQjBsUs6Qpuxw+1BApPGhFw15mQComucl7 5+cTlpUtrdWP7pt60QAH+vMDrmbaPEjHeLrDnwZpo+gxBmUgi+PnrbmrQ9/0XJwgFDhs rjIZRVDiWOMA3nouP5hqs/j8irRlTabk18UUx8t02xLYRzfvgLkFGsXx9efUMk0IE9+p plWQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j10si14663747ede.70.2019.10.15.04.43.45; Tue, 15 Oct 2019 04:44:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730828AbfJOKg0 (ORCPT + 99 others); Tue, 15 Oct 2019 06:36:26 -0400 Received: from mx2.suse.de ([195.135.220.15]:33850 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726441AbfJOKg0 (ORCPT ); Tue, 15 Oct 2019 06:36:26 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 725E6AE39; Tue, 15 Oct 2019 10:36:24 +0000 (UTC) Date: Tue, 15 Oct 2019 12:36:23 +0200 From: Michal Hocko To: Konstantin Khlebnikov Cc: linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Vladimir Davydov , Johannes Weiner Subject: Re: [PATCH] mm/memcontrol: update lruvec counters in mem_cgroup_move_account Message-ID: <20191015103623.GX317@dhcp22.suse.cz> References: <157112699975.7360.1062614888388489788.stgit@buzz> <20191015082048.GU317@dhcp22.suse.cz> <3b73e301-ea4a-5edb-9360-2ae9b4ad9f69@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3b73e301-ea4a-5edb-9360-2ae9b4ad9f69@yandex-team.ru> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? > > > Fixes: 00f3ca2c2d66 ("mm: memcontrol: per-lruvec stats infrastructure") > > > Signed-off-by: Konstantin Khlebnikov > > > > We want Cc: stable I suspect because broken stats might be really > > misleading. > > > > The patch looks ok to me otherwise > > Acked-by: Michal Hocko > > > > > --- > > > mm/memcontrol.c | 18 ++++++++++++------ > > > 1 file changed, 12 insertions(+), 6 deletions(-) > > > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > > index bdac56009a38..363106578876 100644 > > > --- a/mm/memcontrol.c > > > +++ b/mm/memcontrol.c > > > @@ -5420,6 +5420,8 @@ static int mem_cgroup_move_account(struct page *page, > > > struct mem_cgroup *from, > > > struct mem_cgroup *to) > > > { > > > + struct lruvec *from_vec, *to_vec; > > > + struct pglist_data *pgdat; > > > unsigned long flags; > > > unsigned int nr_pages = compound ? hpage_nr_pages(page) : 1; > > > int ret; > > > @@ -5443,11 +5445,15 @@ static int mem_cgroup_move_account(struct page *page, > > > anon = PageAnon(page); > > > + pgdat = page_pgdat(page); > > > + from_vec = mem_cgroup_lruvec(pgdat, from); > > > + to_vec = mem_cgroup_lruvec(pgdat, to); > > > + > > > spin_lock_irqsave(&from->move_lock, flags); > > > if (!anon && page_mapped(page)) { > > > - __mod_memcg_state(from, NR_FILE_MAPPED, -nr_pages); > > > - __mod_memcg_state(to, NR_FILE_MAPPED, nr_pages); > > > + __mod_lruvec_state(from_vec, NR_FILE_MAPPED, -nr_pages); > > > + __mod_lruvec_state(to_vec, NR_FILE_MAPPED, nr_pages); > > > } > > > /* > > > @@ -5459,14 +5465,14 @@ static int mem_cgroup_move_account(struct page *page, > > > struct address_space *mapping = page_mapping(page); > > > if (mapping_cap_account_dirty(mapping)) { > > > - __mod_memcg_state(from, NR_FILE_DIRTY, -nr_pages); > > > - __mod_memcg_state(to, NR_FILE_DIRTY, nr_pages); > > > + __mod_lruvec_state(from_vec, NR_FILE_DIRTY, -nr_pages); > > > + __mod_lruvec_state(to_vec, NR_FILE_DIRTY, nr_pages); > > > } > > > } > > > if (PageWriteback(page)) { > > > - __mod_memcg_state(from, NR_WRITEBACK, -nr_pages); > > > - __mod_memcg_state(to, NR_WRITEBACK, nr_pages); > > > + __mod_lruvec_state(from_vec, NR_WRITEBACK, -nr_pages); > > > + __mod_lruvec_state(to_vec, NR_WRITEBACK, nr_pages); > > > } > > > #ifdef CONFIG_TRANSPARENT_HUGEPAGE > > -- Michal Hocko SUSE Labs