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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6E70FC7114C for ; Wed, 28 Aug 2024 23:26:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E15DD6B0085; Wed, 28 Aug 2024 19:26:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DC6386B0088; Wed, 28 Aug 2024 19:26:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C8D396B0089; Wed, 28 Aug 2024 19:26:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id AAB3C6B0085 for ; Wed, 28 Aug 2024 19:26:12 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2B636801F6 for ; Wed, 28 Aug 2024 23:26:12 +0000 (UTC) X-FDA: 82503239784.15.B197944 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) by imf19.hostedemail.com (Postfix) with ESMTP id 513FF1A0009 for ; Wed, 28 Aug 2024 23:26:10 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=DmAY60UP; spf=pass (imf19.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.51 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724887500; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fsEnXmXmh28jAN8ip/UVLuy7v0nDD76ZYh++ZDSbnAA=; b=0pYwm3xgOmdfvphP/uSdM4NuXqHhfZKVNoSmnOcgrc+IZbwJDqww1ZUU7pgqMmJhbzfrur hwfoEh/2HK/R+eIkWUvJWfBSI7AFtyAHnDHnsv4RsOoqL0iu+nirR05+QhDl9vvSWjPEuC DO2+6o+vfC6k5apwMW/XnyH0rz3xymE= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=DmAY60UP; spf=pass (imf19.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.51 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724887500; a=rsa-sha256; cv=none; b=gO4NDqDW/FHaYVzgbycDzJA68puxdf8ytVSoIWPMTfG6o/PDZg21hMzIvs3qUin5gj5z37 3FGP6THRV6wDscIvo66GYcnYf0xGaBsiMvLFVSAYNLOOZ7s7CIcaasDpKSvPmBNHaJCyiT bX/FIJiUfARKC/9sY7pTliGW/oB4OUI= Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-367990aaef3so25899f8f.0 for ; Wed, 28 Aug 2024 16:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1724887569; x=1725492369; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fsEnXmXmh28jAN8ip/UVLuy7v0nDD76ZYh++ZDSbnAA=; b=DmAY60UP5X3U9q9cu3+KD/GyhPrCI+9oCgjZnp657+LeDVSKH4VzJZu97nFe+bTC2+ InC9Mj7amuAcxGos8N+Epkm+pnGRT75gS0kng7YcfR51LqCU5NuSEBc1kEq0DTqj/gMC Fn2P1RDV3c0hD4CNFN1groH029amJVB2IHGaXL4cpNgaiaqEluJaBPZ40t0CdDXwPq7r nQkYOjo8P3+FKbZIqg426zAXniI3xfHNt8/yu5fKR705ufbd6PZRNCviIFvoPkcatxb9 +P9ZxrjkLd12XdAq35IGC2LYyb260j1LIAwmUUwHwk+s9+Nz9l0P9OsCdSpx7pFyMBYZ 2yjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724887569; x=1725492369; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fsEnXmXmh28jAN8ip/UVLuy7v0nDD76ZYh++ZDSbnAA=; b=v1U5FhIVEFHv5XSyw3M0RONYkoBzMNum1HUoDjI7ngBUOzzxWVmnOVkhk8qWLdl0Ut KufYYw+r4Q1bMdk68cqdRyI4/5ySPQqG8gkNOm41Rc6kSNz6uswLvVvQ6fBckeEk36VK rDSpAfyL9WanbZ4hoWHr0wk7znpCEsX1eR/zs7x0HsHHB12QWsVsiUDfNg+8M8Ha9yAR JAzrOzedG0g2ZrVsbwKlAo1Pk67caP1bWqHGB9wrGfUk7FtizhBZo7SPvqRJvpuh0qSA mDwUnGVQr3+Tk8dep9NZk6K6X5mJZAegkgys2EeTLoufbwoAhVrqa7psAFaDBIKgXt/n Vkpw== X-Forwarded-Encrypted: i=1; AJvYcCWDRB32i1kk1sKxWES0ozmgs3ntZW3O9fXywGONragAO/D0JjU1QCUHixjhv01pAUvTxO6Q5tUPHQ==@kvack.org X-Gm-Message-State: AOJu0Ywln3r0mjuD3/0IAy9hMqYTUrHU/lsorj7Nthz3P4xnspdiilC7 Xth1BxP+LgA9eNyC03Dw9qkC2RjOUrCvyEqXpbjeMfCl8C3VjS/FxfNf61u6hFgNOBDqvS4DTrr 2mAPmrAijsaFvTpw+vN3H8pVoToXsfTDpZAEu X-Google-Smtp-Source: AGHT+IG5pCwLAoU4sKd/3zRhMlUJ8Wa1316EqcrRN4NtvrZ9INECIPWtXhcYlljVv8GYF5umbGN/AMY7d9HWlHTWyfk= X-Received: by 2002:a5d:6188:0:b0:367:bb20:b3e1 with SMTP id ffacd0b85a97d-3749b585e8cmr613778f8f.51.1724887568192; Wed, 28 Aug 2024 16:26:08 -0700 (PDT) MIME-Version: 1.0 References: <20240827235228.1591842-1-shakeel.butt@linux.dev> In-Reply-To: <20240827235228.1591842-1-shakeel.butt@linux.dev> From: Yosry Ahmed Date: Wed, 28 Aug 2024 16:25:30 -0700 Message-ID: Subject: Re: [PATCH v2] memcg: add charging of already allocated slab objects To: Shakeel Butt Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Vlastimil Babka , David Rientjes , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Eric Dumazet , "David S . Miller" , Jakub Kicinski , Paolo Abeni , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Meta kernel team , cgroups@vger.kernel.org, netdev@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: ni16tfq57w8k7k7hqgfjt58h1nugtjum X-Rspam-User: X-Rspamd-Queue-Id: 513FF1A0009 X-Rspamd-Server: rspam02 X-HE-Tag: 1724887570-517417 X-HE-Meta: U2FsdGVkX1/TLYEpZ4BT3LJoRfxLpbMuVjzyyP+eBZ1DbRwLUTOyVWBVGrez+g55OJpJicjPMaHbiI70MsSI8sMpBtXALyuGC1BwVQ5cj3JCqba8r9MbCLCio68lDsKPEOkZhG8hoMH5YUzem0QfLfMgrI1D2qtovRhPvk2wYJOwZ9ehYyLbPlNXX/UpH4PV0RnDyi/S6sgtn7MI69MM+NVZu1/wyrC29lTJcQ/mTVS48TZoIur4tmiCBAOygwZLqkNX0UzQQMKnDI31Ppe0tASduseLkMQAGGqpzwHLw7QXHQaPXE0FV6DDKcjqh8SUpUJzOClY1Qc6oZpGOAowt2ZxSLFalJyIAETXOmaoBOyP23OShMa9mGTSiAE7rw4rFmRF/narHmLP2UzE80VE/IG+kSp/gAtPcpR4dSaqCiFhxK+Je5lBE41Tp5vifee8V/c1pKsSd2a7Z5nHMXMU9mKBVPEX2+e6ZmHQ18qsnV9QsyCOG0DQriLdYMoROVNBgsUmc6o8dxvN1Nhld0e13RomcfCnZO3/LVZRN2VG9+L8NMFjrSKZzNSoE+zd8xPa6xTnLQzteaZMe8cJcZr4F7i1Og1wDHxsnk7JkELoGdrPpHdfPB4NnMSOmIZ9sEp/NJdvGJclSkmzaXvsHDKKE+dmhGcr09MIpxJSQlIV7j1JpKqkbIAo9T8OK3XKHHhyfGEuqRXgmvkAqelTlB13nm/a7rTt8ijmF0ixehOEoOH5VQjTseJPcmSOaU7L7wojbFSMEVsBLPTOejyYkw1j7+0bfygRA1yUg26QjWU658n8yFMi9W7KseqlYQak/KLd9VVG7dP6nS5f3iYetTJbEVR7xdks9htlsMnntlVvRFjdydUKYVaHQesYQPiGopJcFWeRzl+xaHekcPwcbALFKj7Z4b65gkK6WUhfatcAjBEGRidxkkFkejtg3LeDOcG+MHPea1xrzlKnygRKH4j QjPi0o6Y Wa8ubcQY/lEYTWS7G7Iz6eiQdCdmEr9LHyZthRAvD0rIdguEqL7r5gIc1wRg8u76Y92neB2WE6eP6/kRS0kNSS1iIVTEnnpNmMgwK+cJTcu1TSJktomNvf8zNst3XZVnLxD/iCmT1tna8PJmBI4zy4rPcnznvs6VlAjZxL73wlIk7Atu/WsVlr7ewJv7CUyxNKX1iI2E054TwZDoSbzP1GPSVZNQLMG8MYdwT1WXlHYc1W5Ssy2fXsgzjpgvEH5hVdYrPndQaD9H7FTuhAtJOPMbsU82Lnv7uTl9FWfz/II9t0cQbwJsXeogny8EsYfEvgPkB7uc5JqcaVJfNsJC/DcyPFTwPKdho3Nx6 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: List-Subscribe: List-Unsubscribe: On Tue, Aug 27, 2024 at 4:52=E2=80=AFPM Shakeel Butt wrote: > > At the moment, the slab objects are charged to the memcg at the > allocation time. However there are cases where slab objects are > allocated at the time where the right target memcg to charge it to is > not known. One such case is the network sockets for the incoming > connection which are allocated in the softirq context. > > Couple hundred thousand connections are very normal on large loaded > server and almost all of those sockets underlying those connections get > allocated in the softirq context and thus not charged to any memcg. > However later at the accept() time we know the right target memcg to > charge. Let's add new API to charge already allocated objects, so we can > have better accounting of the memory usage. > > To measure the performance impact of this change, tcp_crr is used from > the neper [1] performance suite. Basically it is a network ping pong > test with new connection for each ping pong. > > The server and the client are run inside 3 level of cgroup hierarchy > using the following commands: > > Server: > $ tcp_crr -6 > > Client: > $ tcp_crr -6 -c -H ${server_ip} > > If the client and server run on different machines with 50 GBPS NIC, > there is no visible impact of the change. > > For the same machine experiment with v6.11-rc5 as base. > > base (throughput) with-patch > tcp_crr 14545 (+- 80) 14463 (+- 56) > > It seems like the performance impact is within the noise. > > Link: https://github.com/google/neper [1] > Signed-off-by: Shakeel Butt > --- > v1: https://lore.kernel.org/all/20240826232908.4076417-1-shakeel.butt@lin= ux.dev/ > Changes since v1: > - Correctly handle large allocations which bypass slab > - Rearrange code to avoid compilation errors for !CONFIG_MEMCG builds > > RFC: https://lore.kernel.org/all/20240824010139.1293051-1-shakeel.butt@li= nux.dev/ > Changes since the RFC: > - Added check for already charged slab objects. > - Added performance results from neper's tcp_crr > > include/linux/slab.h | 1 + > mm/slub.c | 51 +++++++++++++++++++++++++++++++++ > net/ipv4/inet_connection_sock.c | 5 ++-- > 3 files changed, 55 insertions(+), 2 deletions(-) > > diff --git a/include/linux/slab.h b/include/linux/slab.h > index eb2bf4629157..05cfab107c72 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -547,6 +547,7 @@ void *kmem_cache_alloc_lru_noprof(struct kmem_cache *= s, struct list_lru *lru, > gfp_t gfpflags) __assume_slab_alignment __mal= loc; > #define kmem_cache_alloc_lru(...) alloc_hooks(kmem_cache_alloc_lru_= noprof(__VA_ARGS__)) > > +bool kmem_cache_charge(void *objp, gfp_t gfpflags); > void kmem_cache_free(struct kmem_cache *s, void *objp); > > kmem_buckets *kmem_buckets_create(const char *name, slab_flags_t flags, > diff --git a/mm/slub.c b/mm/slub.c > index c9d8a2497fd6..8265ea5f25be 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -2185,6 +2185,43 @@ void memcg_slab_free_hook(struct kmem_cache *s, st= ruct slab *slab, void **p, > > __memcg_slab_free_hook(s, slab, p, objects, obj_exts); > } > + > +#define KMALLOC_TYPE (SLAB_KMALLOC | SLAB_CACHE_DMA | \ > + SLAB_ACCOUNT | SLAB_RECLAIM_ACCOUNT) > + > +static __fastpath_inline > +bool memcg_slab_post_charge(void *p, gfp_t flags) > +{ > + struct slabobj_ext *slab_exts; > + struct kmem_cache *s; > + struct folio *folio; > + struct slab *slab; > + unsigned long off; > + > + folio =3D virt_to_folio(p); > + if (!folio_test_slab(folio)) { > + return __memcg_kmem_charge_page(folio_page(folio, 0), fla= gs, > + folio_order(folio)) =3D= =3D 0; > + } > + > + slab =3D folio_slab(folio); > + s =3D slab->slab_cache; > + > + /* Ignore KMALLOC_NORMAL cache to avoid circular dependency. */ > + if ((s->flags & KMALLOC_TYPE) =3D=3D SLAB_KMALLOC) > + return true; Taking a step back here, why do we need this? Which circular dependency are we avoiding here?