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 EE757E7AD57 for ; Tue, 3 Oct 2023 14:23:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2ABFC8D007B; Tue, 3 Oct 2023 10:23:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 25BB48D0003; Tue, 3 Oct 2023 10:23:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 14B318D007B; Tue, 3 Oct 2023 10:23:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 03F428D0003 for ; Tue, 3 Oct 2023 10:23:00 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7B211160366 for ; Tue, 3 Oct 2023 14:22:59 +0000 (UTC) X-FDA: 81304366878.27.A1BAC46 Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by imf06.hostedemail.com (Postfix) with ESMTP id 4BDD9180002 for ; Tue, 3 Oct 2023 14:22:57 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=fnbHfGTL; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf06.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.170 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696342977; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=mQJcLp1PNbZ/HCxUuAL8GIttYWoNS8rEFxPDJqSSreg=; b=QbhX8MrHamZ0/R8n4wvos6A4hQv0BKkk8eKrDLCy4fMifY+QQBn9JYfVoMckPJ6Q/1GNVn gDvmzIst2VOXMqHFS7x8UoglbENcWDjibkzVwl05bFeLOJPpjenbPa7Y7AfASzAkIiolX9 f5BdpuMxy+17Eoq7yZyYFihbNeGHUCM= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=fnbHfGTL; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf06.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.170 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696342977; a=rsa-sha256; cv=none; b=fWFFBUyULO49RnXoVSMaTARiYAzCmBbw9CUUGd4fedzb8o2GcdHnsOtkEbU46+YRTyXeyU dPQtn8GZbKUbvSC4Nh5mFE3QmF3mZLWgUgJrcIsl5QiASW7Ch002heZNSn6zRT6Ao86eSN RX3Z3878oHmWuaEmvdtRTm4V/44RiyI= Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-7741c2fae49so73757685a.0 for ; Tue, 03 Oct 2023 07:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1696342976; x=1696947776; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=mQJcLp1PNbZ/HCxUuAL8GIttYWoNS8rEFxPDJqSSreg=; b=fnbHfGTLpX84Ajd2FJpZwOXTR2EyHrRuo27EUKFjR4Nnshu4w4S7qbShOtihvnP99d b31Is+HCF4NUH1heCa64S4GNkbD6/t8dleYC7nTGSD8YkP4O9WTwrD2zxtohvxP/uwEy WVqqzkOVlsPBpZcvS6X0EoM3zpwrccACYRWcoK0TMvKT49I2cAfKDZb9mXLV+0bN+MNg fQ5P1LhzhW2GL5EHmbijVkA//ar2c8gXNI0xJwJiH+5E3QlARoiRBbzd18HZBZADQlbR +a22Yg8uQIe+Zm5Ajv23ftXRaAYHmMTrfEgUN7qOLJgeHoVgAMdMXzx89KCxrdX2bDSA W3jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696342976; x=1696947776; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mQJcLp1PNbZ/HCxUuAL8GIttYWoNS8rEFxPDJqSSreg=; b=MgYzxGxV4Q2admvC3zyyYjfw932x2iXyh0shqeP0lJAQwtPkRbBuN1vU9W3ai6gS7s qprvNKwGXPzhcgTV2enf+/YmEg/KO8tNaFRSVpfFjs9+2ixVEZGAFfx4WhkDG9VuKyGd xqTldkKNp6qZhG9wtkHS9cNnHvjZqmzH9f9R7OEsPjRjuJd/Cb1QyaAExj+K1Rz4tEH1 VLj3aHH3RGC53k2uHc7e2uRYjiCwAutu/6rhKM6aNsv/vHuT9gEX09RGKI3n8ii/dgh2 /YncR4qb8fCDokFkOGmpvR3+12fGFzfosN3QfR714tXZhHbj4YDVoFSYI4sSqRCNCyKD 77nQ== X-Gm-Message-State: AOJu0Ywt85L0YQ2TXF0g+dY8/bEZ/b0S1LVBtcT7Hp8PsPkLYDFxvQoN YgqXEXSBUnI6QBWokZRB5p/Ygg== X-Google-Smtp-Source: AGHT+IGv7PLU7uRYjnFUgK7YvvEdjfi3advrrLLcN7FRUz6vDMpEs0fGL3cW+2lAdwL2wIvXdR0haw== X-Received: by 2002:a0c:e18a:0:b0:65d:d:a114 with SMTP id p10-20020a0ce18a000000b0065d000da114mr15681428qvl.55.1696342976103; Tue, 03 Oct 2023 07:22:56 -0700 (PDT) Received: from localhost (2603-7000-0c01-2716-3012-16a2-6bc2-2937.res6.spectrum.com. [2603:7000:c01:2716:3012:16a2:6bc2:2937]) by smtp.gmail.com with ESMTPSA id h9-20020a0cab09000000b006616fbcc077sm519329qvb.129.2023.10.03.07.22.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Oct 2023 07:22:55 -0700 (PDT) Date: Tue, 3 Oct 2023 10:22:55 -0400 From: Johannes Weiner To: Roman Gushchin Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Michal Hocko , Shakeel Butt , Muchun Song , Dennis Zhou , Andrew Morton Subject: Re: [PATCH rfc 2/5] mm: kmem: add direct objcg pointer to task_struct Message-ID: <20231003142255.GE17012@cmpxchg.org> References: <20230927150832.335132-1-roman.gushchin@linux.dev> <20230927150832.335132-3-roman.gushchin@linux.dev> <20231002201254.GA8435@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 4BDD9180002 X-Stat-Signature: eozb49znwydmccwhdxn6zppkiydkfcaq X-Rspam-User: X-HE-Tag: 1696342977-97825 X-HE-Meta: U2FsdGVkX18OhbldGdy9qk+DWNwX2cxNVlCXYESehRRmyJuieeqWL7zMfTDy7KhtkArtsSU2sltdFiWsp1kvuKSnFzasKnBLqiaWkyfzlGFbvXC2mG0mLShIvPLfp9rn13lM7qwUTvbdEmtod3HMqaTMVyOzvlKhIeNX8UlRCQNxvM6YT0FdoGJaIOjF0BqNlv+YksUX3u0HbICoP9fS4mbIYStnJ+t8LMBMbTi3umghwBnjHI4VCxp+v5GYl+lj6Ac8xftRtNwW+PJHQMnrEvWtIQVOLs65SrNwck8wpjLl0Swji5GkalYHdcXIDHvCGXIxEnCPe+8Vovbm74u/8gpFaFgyRPT8MX8zo30+2yiTQoGCYWd7oonuifyTvXfbkTyL/pQU2pxHx8xld677XRnOvkZSo113QRCnnFBYXcx1oPJMWgk36GwhlG/5zER2aZH+S22fottYaetdUPfPMaYCuEl2GEO//mBrbvqbPEW1VicL4TcZIsI4WiAtnXlqWIhGWp1vETKufbbJnPzOAqUWBTP2udm6g2jKzLFWvd0QPTmdPyQM1RRsCjndD7EPwWOoVmXe6BoMqmQsCEDSCZWDJN2Lmu3vllAzwNeconwVHHyM51mwg03tW7x6VklKF3f+QrT6ETaAJyQtiivlP2GRCNeZL2rryB1SE8iL3htVtGBeN+DvkNdr0hIarcGSwaOOHUOdQSsnxiglRNLv4H4pbYjfWVkXW1YAyJfeyEUfsquUxinJFlfWB6OYNbZpvc04MjWUhARtm8Y6rxHpM9ILRMK4/AG8fayWU6Dgj3PcxbEwsppWjer6tDR0WCzBr7gBZ6s+bKx/kkKP64zKApwGgBezznvJ5a/el7wjMRE51PC1hTJeFYlL4TXtPuseNo4Y+uVcFihIyvAmyuMV3I1rqGykmfc4W7xx+r+nOaloupwZBbPW8JNsrmq09p4G02Wo5JNMsMiKni4uGCu J5uwmD89 4R3pGx5xe8iBhMRivYVRADmFAULOjRzdVwG1cEqYlsgFtorvmOws+0aTMLlri5/04asiSW4047OcUY0yRPvSp8MEcCVi+x63ga2RgQRhYc35EZV7MAkJlzJk3hchmcRvBvPuN206NfvPZ6TofOppDBQDlYlk62kq8rE8XjIZTDwXNlnERD23CKmqj72CoNgoCXMhvtAVmkAV41HmmaQVaNh6MdutmnuDW2QAy9nwzBzbNYqBLqLGcSqyuuJeG3KtdC4IyCI/KC+Jt3LbVrTkX7afLsWGyIJbEHH4x6ZZpnCGTHLvMIMJ2ksbPHMuGsldhMAHspxsdb4vMOYytY21ApE+KjzIXJUtf94GBvhTQcRt5QvIeosT7ApGIvLm35Gh/wt9IpHCOhPKlYIDB17gr0gmKZm6hJbPmf2RA/J96mV02fcSbkIWymF7urZjUXLeYFSNK 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, Oct 02, 2023 at 03:03:48PM -0700, Roman Gushchin wrote: > On Mon, Oct 02, 2023 at 04:12:54PM -0400, Johannes Weiner wrote: > > On Wed, Sep 27, 2023 at 08:08:29AM -0700, Roman Gushchin wrote: > > > @@ -3001,6 +3001,47 @@ static struct obj_cgroup *__get_obj_cgroup_from_memcg(struct mem_cgroup *memcg) > > > return objcg; > > > } > > > > > > +static DEFINE_SPINLOCK(current_objcg_lock); > > > + > > > +static struct obj_cgroup *current_objcg_update(struct obj_cgroup *old) > > > +{ > > > + struct mem_cgroup *memcg; > > > + struct obj_cgroup *objcg; > > > + unsigned long flags; > > > + > > > + old = current_objcg_clear_update_flag(old); > > > + if (old) > > > + obj_cgroup_put(old); > > > + > > > + spin_lock_irqsave(¤t_objcg_lock, flags); > > > + rcu_read_lock(); > > > + memcg = mem_cgroup_from_task(current); > > > + for (; memcg != root_mem_cgroup; memcg = parent_mem_cgroup(memcg)) { > > > + objcg = rcu_dereference(memcg->objcg); > > > + if (objcg && obj_cgroup_tryget(objcg)) > > > + break; > > > + objcg = NULL; > > > + } > > > + rcu_read_unlock(); > > > > Can this tryget() actually fail when this is called on the current > > task during fork() and attach()? A cgroup cannot be offlined while > > there is a task in it. > > Highly theoretically it can if it races against a migration of the current > task to another memcg and the previous memcg is getting offlined. Ah right, if this runs between css_set_move_task() and ->attach(). The cache would be briefly updated to a parent in the old hierarchy, but then quickly reset from the ->attach(). Can you please add a comment along these lines? > I actually might make sense to apply the same approach for memcgs as well > (saving a lazily-updating memcg pointer on task_struct). Then it will be > possible to ditch this "for" loop. But I need some time to master the code > and run benchmarks. Idk if it will make enough difference to justify the change. Yeah the memcg pointer is slightly less attractive from an optimization POV because it already is a pretty direct pointer from task through the cset array. If you still want to look into it from a simplification POV that sounds reasonable, but IMO it would be fine with a comment. > > > @@ -6345,6 +6393,22 @@ static void mem_cgroup_move_task(void) > > > mem_cgroup_clear_mc(); > > > } > > > } > > > + > > > +#ifdef CONFIG_MEMCG_KMEM > > > +static void mem_cgroup_fork(struct task_struct *task) > > > +{ > > > + task->objcg = (struct obj_cgroup *)0x1; > > > > dup_task_struct() will copy this pointer from the old task. Would it > > be possible to bump the refcount here instead? That would save quite a > > bit of work during fork(). > > Yeah, it should be possible. It won't save a lot, but I agree it makes > sense. I'll take a look and will prepare a separate patch for this. I guess the hairiest part would be synchronizing against a migration because all these cgroup core callbacks are unlocked. Would it make sense to add ->fork_locked() and ->attach_locked() callbacks that are dispatched under the css_set_lock? Then this could be a simple if (p && !(p & 0x1)) obj_cgroup_get(), which would certainly be nice to workloads where fork() is hot, with little downside otherwise.