Received: by 2002:a25:1104:0:0:0:0:0 with SMTP id 4csp494948ybr; Fri, 22 May 2020 11:29:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwbVHZwuKcidfLYov0GZvi3w0qGqL/CWuGXg9Bzj3maN8BVzP4kzFSauAsBTB0PnGDib6nS X-Received: by 2002:aa7:db45:: with SMTP id n5mr3900928edt.147.1590172156132; Fri, 22 May 2020 11:29:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590172156; cv=none; d=google.com; s=arc-20160816; b=0zvA1S2dUWHrq9EINY24g0udOmdqhwtsS8R4j5UGT7VY7T3ahut+kRAq4TZG2EeNS6 QqP/qFJLxJJEZpHEVCmIdMelNITfd+K+Zoo3DrEUMb+Z7Z6v7wJiIcKQ7vOxSbiM2xcj zT3uaJJv0wGe6QqH74Nu232IzWCrm6w1cjmQDR6nWRnQx1zzgQJgli6PFKYWaAazIJTw mt1MQ61NSyKyV196cpfGRsD5UVFGHXHZzMkO77kG8x5MhjuBwxGuIGD91vRHZXR4UCfP M/ZpgNcrkyFKVA/PTjc4n3KDGoeleBR8mB+t6A/RXCykfH48bNdrwubCR5paWkE+ddaS XWhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=YFNlQmT8awiJkR9KCQVgBdF0b6wXBb/TL6ZdmQYQ3fA=; b=Eeva4+s6GR5FzPvA/Fa0LjI1AE9AOwwePKGh1a/8ptBPWf1G7zkfYFON8Xx0pYpXN7 HQ8EsAszpcUZ8U7QKeiLqNfdlVbWezcLVrpOUZ1cPVIt9hpCx1X6TabI1o8p35yMdodX /QrjxtsOdGJChURVn/QHySym/kjy34V0lptxoS3YcsCJK1QSqf96NLOI3h1D9PKUDBXu bVMWRQ5s5ZFjlpPNNf2A6Ctn1cnzb6fG4vgWYjUsjgfuxO9KwRXIb0txcRRuzMS28apJ LfCHNGFqIKAspKeJ0/EujKv/Lbsjj6tFOKBgECCL7IhJ1LpSuRoTJSoI5IP2jfFEZnPa WGWg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id df16si5086157edb.158.2020.05.22.11.28.53; Fri, 22 May 2020 11:29:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730842AbgEVS1S (ORCPT + 99 others); Fri, 22 May 2020 14:27:18 -0400 Received: from mx2.suse.de ([195.135.220.15]:34168 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726373AbgEVS1R (ORCPT ); Fri, 22 May 2020 14:27:17 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 41C61ACE6; Fri, 22 May 2020 18:27:19 +0000 (UTC) Subject: Re: [PATCH v3 07/19] mm: memcg/slab: allocate obj_cgroups for non-root slab pages To: Roman Gushchin , Andrew Morton Cc: Johannes Weiner , Michal Hocko , linux-mm@kvack.org, kernel-team@fb.com, linux-kernel@vger.kernel.org References: <20200422204708.2176080-1-guro@fb.com> <20200422204708.2176080-8-guro@fb.com> From: Vlastimil Babka Message-ID: <930fb5f4-0666-5db0-0fcf-a78171bf29be@suse.cz> Date: Fri, 22 May 2020 20:27:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200422204708.2176080-8-guro@fb.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/22/20 10:46 PM, 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 Reviewed-by: Vlastimil Babka But I have a suggestion: ... > --- a/include/linux/slub_def.h > +++ b/include/linux/slub_def.h > @@ -191,4 +191,6 @@ static inline unsigned int obj_to_index(const struct kmem_cache *cache, > cache->reciprocal_size); > } > > +extern int objs_per_slab(struct kmem_cache *cache); > + > #endif /* _LINUX_SLUB_DEF_H */ > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 7f87a0eeafec..63826e460b3f 100644 ... > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -5992,4 +5992,9 @@ ssize_t slabinfo_write(struct file *file, const char __user *buffer, > { > return -EIO; > } > + > +int objs_per_slab(struct kmem_cache *cache) > +{ > + return oo_objects(cache->oo); > +} > #endif /* CONFIG_SLUB_DEBUG */ > It's somewhat unfortunate to function call just for this. Although perhaps compiler can be smart enough as charge_slab_page() (that callse objs_per_slab()) is inline and called from alloc_slab_page() which is also in mm/slub.c. But it might be also a bit wasteful in case SLUB doesn't manage to allocate its desired order, but smaller. The actual number of objects is then in page->objects. So ideally this should use something like objs_per_slab_page(cache, page) where SLAB supplies cache->num and SLUB page->objects, both implementations inline, and ignoring the other parameter?