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.2 required=3.0 tests=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 B22CCC47253 for ; Thu, 30 Apr 2020 16:29:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 77A0C2070B for ; Thu, 30 Apr 2020 16:29:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 77A0C2070B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 148928E0005; Thu, 30 Apr 2020 12:29:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F9AA8E0001; Thu, 30 Apr 2020 12:29:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 00E178E0005; Thu, 30 Apr 2020 12:29:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0145.hostedemail.com [216.40.44.145]) by kanga.kvack.org (Postfix) with ESMTP id DA6318E0001 for ; Thu, 30 Apr 2020 12:29:51 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 8FB14824805A for ; Thu, 30 Apr 2020 16:29:51 +0000 (UTC) X-FDA: 76765057782.01.self94_1bd59ad837919 X-HE-Tag: self94_1bd59ad837919 X-Filterd-Recvd-Size: 2878 Received: from gentwo.org (gentwo.org [3.19.106.255]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Thu, 30 Apr 2020 16:29:51 +0000 (UTC) Received: by gentwo.org (Postfix, from userid 1002) id 8B6B13EEE2; Thu, 30 Apr 2020 16:29:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 8A3B03E998; Thu, 30 Apr 2020 16:29:50 +0000 (UTC) Date: Thu, 30 Apr 2020 16:29:50 +0000 (UTC) From: Christopher Lameter X-X-Sender: cl@www.lameter.com To: Roman Gushchin cc: Andrew Morton , Johannes Weiner , Michal Hocko , linux-mm@kvack.org, kernel-team@fb.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 04/19] mm: slub: implement SLUB version of obj_to_index() In-Reply-To: <20200427164638.GC114719@carbon.DHCP.thefacebook.com> Message-ID: References: <20200422204708.2176080-1-guro@fb.com> <20200422204708.2176080-5-guro@fb.com> <20200423000530.GA63356@carbon.lan> <20200425024625.GA107755@carbon.lan> <20200427164638.GC114719@carbon.DHCP.thefacebook.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Mon, 27 Apr 2020, Roman Gushchin wrote: > > Why do you need this? Just slap a pointer to the cgroup as additional > > metadata onto the slab object. Is that not much simpler, safer and faster? > > > > So, the problem is that not all slab objects are accounted, and sometimes > we don't know if advance if they are accounted or not (with the current semantics > of __GFP_ACCOUNT and SLAB_ACCOUNT flags). So we either have to increase > the size of ALL slab objects, either create a pair of slab caches for each size. > > The first option is not that cheap in terms of the memory overhead. Especially > for those who disable cgroups using a boot-time option. If the cgroups are disabled on boot time then you can switch back to the compact version. Otherwise just add a pointer to each object. It will make it consistent and there is not much memory wastage. The problem comes about with the power of 2 caches in the kmalloc array. If one keeps the "natural alignment" instead of going for the normal alignment of slab caches then the alignment will cause a lot of memory wastage and thus the scheme of off slab metadata is likely going to be unavoidable. But I think we are just stacking one bad idea onto another here making things much more complex than they could be. Well at least this justifies all our jobs .... (not mine I am out of work... hehehe)