Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4110869ybl; Mon, 3 Feb 2020 12:48:13 -0800 (PST) X-Google-Smtp-Source: APXvYqwx38c+Oh+395l2SD3ubjgV7S/9zDYo4UtYE44ZJeqD2kDzlCqc/BXWjpkzVamvMGKaz+Cp X-Received: by 2002:aca:503:: with SMTP id 3mr704003oif.106.1580762893743; Mon, 03 Feb 2020 12:48:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580762893; cv=none; d=google.com; s=arc-20160816; b=iaLzhD5Ch7d5q+Amo/WRQF19142w4choQXPJSo82EcpeJthuvDRty48dUkeD2Gm2bv BEJhKRMfE4PzXI7/yr+31ezZuCZDt9TlBbL7FQinz5uADl8RzsDPsv8YlmPWp9fQZCih hvu2eZz8FKrT/ZnhEsarIno2YkVcDVYFKRaeHk9LMi+JJXeMqKXkOiGEFruD5dlWsCRC Tg4aCDOpRwfgN6s1hxKhgvJdm6GIGIS70OqwhiQ7SiTiHdAnDxEmfZWpRz5nKjkMtY9K DbR2cqWfadUBI7uN4HFJWqW+higNu1wp/lSw2LH5G2ziLvOCPHmRRD8Ke4So48a5hCDF JqTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=/Dyb5P8cYEisIFp4I9bV09OPYylTy1VzXVbN2SCBhjo=; b=htSQFEkmJtJsVwMN1GC8c4suxy7pS/uCgSYsXih7Sfk4kAsBqF3RSzMyE7QZ1GZSwo HQmVmn4YDnAk0946TyuTHIeuPMrAe/VdZ3qHlnNH3xbBiHoyhLmcWrohdFuh3jUVvDHG FV94PQwEVlhXQoWlBUSEaxEAlNXSTZ7zNY/GQosVJN1OqduM60RSmzBU+vX5Kz49ICjv d35cHw9HzO/z63MIgu2dDgFvOP3IAQmZd7rEf/iRLMmLKBhvb0DoIgcQvcIqdz+37f9G fXxW6/noGcODV6+3TldxXW4IWX8BPPcFpeRSZfO0E4hjxj/xNTyq6U2Juc72wjjJ2Dhf qnaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=HDxZXECh; 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=cmpxchg.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c7si1189408ots.38.2020.02.03.12.47.59; Mon, 03 Feb 2020 12:48:13 -0800 (PST) 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; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=HDxZXECh; 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=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726994AbgBCUqa (ORCPT + 99 others); Mon, 3 Feb 2020 15:46:30 -0500 Received: from mail-qv1-f66.google.com ([209.85.219.66]:41425 "EHLO mail-qv1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726278AbgBCUqa (ORCPT ); Mon, 3 Feb 2020 15:46:30 -0500 Received: by mail-qv1-f66.google.com with SMTP id s7so7493182qvn.8 for ; Mon, 03 Feb 2020 12:46:29 -0800 (PST) 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=/Dyb5P8cYEisIFp4I9bV09OPYylTy1VzXVbN2SCBhjo=; b=HDxZXEChqr8YGF0MhKTxj3c2pDA138gHfw/6zgEsOxoFoaRnu9e+rh9ivPg5RvQK04 rj9iNBrqdXd21ZlvGOGXE82Coh4XHqJnAtVsfX6dlkVF7egKmkzt7by0DHYGUMabuijM PR7eVPslVTo/JGx08pjzWnRjui/OWXwkrLRgpJEjJ+z5LFhyWL2RuD0tR25qQYRUJJw2 tYjKHJSu8Gw6jNRy30qk7Wtdy6B88BX7aBbbaFXoMuL+j2/x4Zgvsyg7HiujAb9MeFis c6Kx/xigRFf4tVPdNvIF6ATPDTm1xfDu12fZMtyh8dMrEz+Z4RF1LMLbxzlPrIhb66i3 rZUg== 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=/Dyb5P8cYEisIFp4I9bV09OPYylTy1VzXVbN2SCBhjo=; b=qXf7RgiPsZFl1UNPS0AQNZQFVSElmeafzuPoHKIgbU5kQpRDtqO5yhdIIFYDoxt5oN 952iQBXvbVi4ECGXtPKL1d6pYhiT6RSyn1lcLkgBowP4EP9LCB/HmcKq749wsfSTd347 SuKIVBmtCujdkpCPpIVgZhVz5qIrjmtDXA65SgMoL6gnXge0cIXDSJsLbd8tK7g4mHDZ Is6gdaCNslkGb8E1wTE7BOEHBIvcqwbKPBGULLJ0aiAQXLukAO+7mrV9fwZQOUucl0IY 92gLG6Ti/PjwcAGs3LeW0sJTSC6MCpJDXO/zW4SEtHCTpL24qYiznnFnhendVrPotQ0y kLHw== X-Gm-Message-State: APjAAAXqHMD5i+p9HzLDd0qYZwKWkXiok7Ywl7xxXv+avEiTT0Ajiq4l BIzRt9FfWodE7NIdIg07uDMkSg== X-Received: by 2002:ad4:518d:: with SMTP id b13mr24279887qvp.141.1580762788875; Mon, 03 Feb 2020 12:46:28 -0800 (PST) Received: from localhost ([2620:10d:c091:500::2:6320]) by smtp.gmail.com with ESMTPSA id t15sm9609895qkg.49.2020.02.03.12.46.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Feb 2020 12:46:28 -0800 (PST) Date: Mon, 3 Feb 2020 15:46:27 -0500 From: Johannes Weiner To: Roman Gushchin Cc: linux-mm@kvack.org, Andrew Morton , Michal Hocko , Shakeel Butt , Vladimir Davydov , linux-kernel@vger.kernel.org, kernel-team@fb.com, Bharata B Rao , Yafang Shao Subject: Re: [PATCH v2 16/28] mm: memcg/slab: allocate obj_cgroups for non-root slab pages Message-ID: <20200203204627.GB6380@cmpxchg.org> References: <20200127173453.2089565-1-guro@fb.com> <20200127173453.2089565-17-guro@fb.com> <20200203182756.GG1697@cmpxchg.org> <20200203183452.GB3700@xps.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200203183452.GB3700@xps.dhcp.thefacebook.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 03, 2020 at 10:34:52AM -0800, Roman Gushchin wrote: > On Mon, Feb 03, 2020 at 01:27:56PM -0500, Johannes Weiner wrote: > > On Mon, Jan 27, 2020 at 09:34:41AM -0800, Roman Gushchin wrote: > > > Allocate and release memory to store obj_cgroup pointers for each > > > non-root slab page. Reuse page->mem_cgroup pointer to store a pointer > > > to the allocated space. > > > > > > To distinguish between obj_cgroups and memcg pointers in case > > > when it's not obvious which one is used (as in page_cgroup_ino()), > > > let's always set the lowest bit in the obj_cgroup case. > > > > > > Signed-off-by: Roman Gushchin > > > --- > > > include/linux/mm.h | 25 ++++++++++++++++++-- > > > include/linux/mm_types.h | 5 +++- > > > mm/memcontrol.c | 5 ++-- > > > mm/slab.c | 3 ++- > > > mm/slab.h | 51 +++++++++++++++++++++++++++++++++++++++- > > > mm/slub.c | 2 +- > > > 6 files changed, 83 insertions(+), 8 deletions(-) > > > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > > index 080f8ac8bfb7..65224becc4ca 100644 > > > --- a/include/linux/mm.h > > > +++ b/include/linux/mm.h > > > @@ -1264,12 +1264,33 @@ static inline void set_page_links(struct page *page, enum zone_type zone, > > > #ifdef CONFIG_MEMCG > > > static inline struct mem_cgroup *page_memcg(struct page *page) > > > { > > > - return page->mem_cgroup; > > > + struct mem_cgroup *memcg = page->mem_cgroup; > > > + > > > + /* > > > + * The lowest bit set means that memcg isn't a valid memcg pointer, > > > + * but a obj_cgroups pointer. In this case the page is shared and > > > + * isn't charged to any specific memory cgroup. Return NULL. > > > + */ > > > + if ((unsigned long) memcg & 0x1UL) > > > + memcg = NULL; > > > + > > > + return memcg; > > > > That should really WARN instead of silently returning NULL. Which > > callsite optimistically asks a page's cgroup when it has no idea > > whether that page is actually a userpage or not? > > For instance, look at page_cgroup_ino() called from the > reading /proc/kpageflags. But that checks PageSlab() and implements memcg_from_slab_page() to handle that case properly. And that's what we expect all callsites to do: make sure that the question asked actually makes sense, instead of having the interface paper over bogus requests. If that function is completely racy and PageSlab isn't stable, then it should really just open-code the lookup, rather than require weakening the interface for everybody else. > > > static inline struct mem_cgroup *page_memcg_rcu(struct page *page) > > > { > > > + struct mem_cgroup *memcg = READ_ONCE(page->mem_cgroup); > > > + > > > WARN_ON_ONCE(!rcu_read_lock_held()); > > > - return READ_ONCE(page->mem_cgroup); > > > + > > > + /* > > > + * The lowest bit set means that memcg isn't a valid memcg pointer, > > > + * but a obj_cgroups pointer. In this case the page is shared and > > > + * isn't charged to any specific memory cgroup. Return NULL. > > > + */ > > > + if ((unsigned long) memcg & 0x1UL) > > > + memcg = NULL; > > > + > > > + return memcg; > > > > Same here. > > > > > } > > > #else > > > static inline struct mem_cgroup *page_memcg(struct page *page) > > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > > > index 270aa8fd2800..5102f00f3336 100644 > > > --- a/include/linux/mm_types.h > > > +++ b/include/linux/mm_types.h > > > @@ -198,7 +198,10 @@ struct page { > > > atomic_t _refcount; > > > > > > #ifdef CONFIG_MEMCG > > > - struct mem_cgroup *mem_cgroup; > > > + union { > > > + struct mem_cgroup *mem_cgroup; > > > + struct obj_cgroup **obj_cgroups; > > > + }; > > > > Since you need the casts in both cases anyway, it's safer (and > > simpler) to do > > > > unsigned long mem_cgroup; > > > > to prevent accidental direct derefs in future code. > > Agree. Maybe even mem_cgroup_data? Personally, I don't think the suffix adds much. The type makes it so the compiler catches any accidental use, and access is very centralized so greppability doesn't matter much.