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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 7C5F7C83001 for ; Tue, 28 Apr 2020 17:45:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 22255208FE for ; Tue, 28 Apr 2020 17:45:39 +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="wkVH2EJT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 22255208FE 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 710548E0005; Tue, 28 Apr 2020 13:45:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C19E8E0001; Tue, 28 Apr 2020 13:45:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AFC88E0005; Tue, 28 Apr 2020 13:45:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0114.hostedemail.com [216.40.44.114]) by kanga.kvack.org (Postfix) with ESMTP id 3FB3E8E0001 for ; Tue, 28 Apr 2020 13:45:39 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E7FEA824934B for ; Tue, 28 Apr 2020 17:45:38 +0000 (UTC) X-FDA: 76757991156.06.spoon82_88896fb373c0f X-HE-Tag: spoon82_88896fb373c0f X-Filterd-Recvd-Size: 5398 Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Apr 2020 17:45:38 +0000 (UTC) Received: by mail-qt1-f194.google.com with SMTP id w29so18028135qtv.3 for ; Tue, 28 Apr 2020 10:45:37 -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; bh=rD6+QlvoXId8Xl+YOpROYQir/HTlVS4cxd5DrH5tJkA=; b=wkVH2EJT5ZocpRW0i5Nm11VGlpqStET8dmjU5iWMCSJSZapiSEk/Tk8SDbPmYwj8H2 wq7iwoOlgfwUt5zoD2zmO77ym6ZH9F0lPTsEvn1jWZV53B/sgJNjxKg9FEHisThz5W7V 8UQfymCU9+C0TT0cU0zPBWWjuIG/mX+aoyS2+OOopFa2mmGAJn64ylaqJPB0JlKKpSIx z2Ql5kXsc3pbPkDuzt8HVlL6UO7BoC/C1X3r0lK1NK7+KePZY+9d4OurFKweZu9hhfz9 otrWaRTtzYTTyBvFfKzmSUinghJUf6n4zVbiU1LIrYgH9Uwrcp5MLs0lrY/nVRWKiSwH Sxow== 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=rD6+QlvoXId8Xl+YOpROYQir/HTlVS4cxd5DrH5tJkA=; b=GTLypyK9FyLvYr+aYz3+4RBPZ1Bya7jSqXK4evS0a4eG6KbG155m/Iz0mBI0jCEbdb VO9qweXOb1Fu6Vza67MhJhhd4YU3mEl7nzuQM2vYmnuokwfi3UTs0bVfzm8yXOJL36t5 nOitXdjfri0Wma9+ZC248eak+FP1AESC5nA3KEuUgyWBj1rH6LdgPs095vQiJb85QiQX pAXIfBJOgt2Jd6jVRrP1qQx/Qi3jzmNx1UiWb5rcVdUj7XHoy7AM8MQj5/O6gdjLbus2 RpSuu9GfG9jLAFVmIZoktVDa1/H4aPfWVsZ/ViwWlRg/GJvzXe8sKbaYVeEmE+L4sTmv ILjw== X-Gm-Message-State: AGi0PuZn/K2JOrapJM7L9FENZSPSrbqS/8m3LCoV/Wg058s36nf3umFl OJp14QZSAYyO7mXQgpEoCR6+aQ== X-Google-Smtp-Source: APiQypIysUUVW77WATeTd/38hXjw0UW7Y8YAHmOnAd8rCltg+U7JxPZaRqJhRGPxNbQ2Eb9LyRAJDw== X-Received: by 2002:ac8:e8f:: with SMTP id v15mr29118246qti.391.1588095937191; Tue, 28 Apr 2020 10:45:37 -0700 (PDT) Received: from localhost (70.44.39.90.res-cmts.bus.ptd.net. [70.44.39.90]) by smtp.gmail.com with ESMTPSA id e4sm13522424qkn.11.2020.04.28.10.45.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Apr 2020 10:45:36 -0700 (PDT) Date: Tue, 28 Apr 2020 13:45:26 -0400 From: Johannes Weiner To: Roman Gushchin Cc: Christopher Lameter , Andrew Morton , 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() Message-ID: <20200428174526.GA88367@cmpxchg.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200427164638.GC114719@carbon.DHCP.thefacebook.com> 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, Apr 27, 2020 at 09:46:38AM -0700, Roman Gushchin wrote: > On Mon, Apr 27, 2020 at 04:21:01PM +0000, Christoph Lameter wrote: > > On Fri, 24 Apr 2020, Roman Gushchin wrote: > > > > > > The patch seems to only use it for setup and debugging? It is used for > > > > every "accounted" allocation???? Where? And what is an "accounted" > > > > allocation? > > > > > > > > > > > > > > Please, take a look at the whole series: > > > https://lore.kernel.org/linux-mm/20200422204708.2176080-1-guro@fb.com/T/#t > > > > > > I'm sorry, I had to cc you directly for the whole thing. Your feedback > > > will be highly appreciated. > > > > > > It's used to calculate the offset of the memcg pointer for every slab > > > object which is charged to a memory cgroup. So it must be quite hot. > > > > > > Ahh... Thanks. I just looked at it. > > > > You need this because you have a separate structure attached to a page > > that tracks membership of the slab object to the cgroup. This is used to > > calculate the offset into that array.... > > > > 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. Both options seem completely disproportionate in their memory cost, and the latter one in terms of code complexity, to avoid the offset calculation. As a share of the total object accounting cost, I'd expect this to be minimal. Does the mult stand out in an annotated perf profile? Is it enough to bring back 500+ lines of code, an additional branch on accounted allocations, and the memory fragmentation of split caches? I highly doubt it.