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 24975C27C4F for ; Sun, 23 Jun 2024 17:59:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 166656B04DE; Sun, 23 Jun 2024 13:59:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 118706B04DF; Sun, 23 Jun 2024 13:59:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF8AA6B04E0; Sun, 23 Jun 2024 13:59:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D0D006B04DE for ; Sun, 23 Jun 2024 13:59:44 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2D6FE12087F for ; Sun, 23 Jun 2024 17:59:44 +0000 (UTC) X-FDA: 82262916288.23.3FD7FCE Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by imf08.hostedemail.com (Postfix) with ESMTP id 47750160016 for ; Sun, 23 Jun 2024 17:59:42 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OSdT9U6U; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf08.hostedemail.com: domain of htejun@gmail.com designates 209.85.210.174 as permitted sender) smtp.mailfrom=htejun@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719165571; a=rsa-sha256; cv=none; b=xTqbrx1Cba8f2CcT+w0bShhCf36ekImDiptpUcCHUvJRLDlezaJGl039NfBHywoAFL0olT O39OHf8PzZj161kMotM7Cliu66ui3GZ32fCsBWLDMUkABm4H268NM+aWdMnQVuFewpy2NN vj8SXjXhBs2BOVuhKV6HewzdG6TsgH4= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OSdT9U6U; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf08.hostedemail.com: domain of htejun@gmail.com designates 209.85.210.174 as permitted sender) smtp.mailfrom=htejun@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719165571; h=from:from:sender: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=vdrAE5syil0L7SoKCEOA2oEKJIMHQaYNbCDQyJApVB8=; b=xdlXtmaYKtba/Xkwy8awKEzyYbWikIxbkCszQHorSDi2WQdPA0j/EFgFXDJeqCAl/3+Dfk e75NtgtRD1l/75hUsDHSiOjTQe8lJS/ubz24OjuJwrbhIEkJzzixkU+afmE26fBSfO73ix gIBOy9DEmmZKckpI0lE729k6pmJ5Bjk= Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-706627ff48dso1196448b3a.1 for ; Sun, 23 Jun 2024 10:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719165581; x=1719770381; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=vdrAE5syil0L7SoKCEOA2oEKJIMHQaYNbCDQyJApVB8=; b=OSdT9U6U23TrO2CdrPUijYiTNZm7hWGqTmJc7V6htlUsQLcaFMIOTku+kZQoLQkpWg EEzx5OpN/N5NRByKZo3bqdtJpzRvsKvzxDhgLLnwxg79qAOslEduZt4Dun9Er5xQegcY za7OSDrjzsQBozw3HZJZ3iGXlKqlCGDc7PF9vegZQnxDQ0MtOvbvF/IhXg6KjQuGMN5d jm1lQPD89snWuvUbeLDZ4XQLB5Drfj9QL4MYBCmD3jJfTb6Vum7caqzptlpuKDuKUGut 85qHYvKzV9HA0pjPDADgtpFNwZrBr1riwMbPHRDzTvDUY6ySS8ZQ6AQnushBCp2T88uw fYUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719165581; x=1719770381; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vdrAE5syil0L7SoKCEOA2oEKJIMHQaYNbCDQyJApVB8=; b=G0bLdsE3TzzB8ptG7nzmqI1SBG7Jy48IJ2QULvh/d0ge2mN36paszV24TDRgTEZWPS Q9o26vNbFWhXpC9ER2JaNub7+Ek4YKQEoqAa04RnOsmrUQ7rNcCyPDEUC/8HIzkseSPU IH3EjkbvS3p9hvLx4P+k06R9Y0NleJsQvYBBROmKAleoMDTWl+2Xy+ThsSnh6JVywq2U KUsHcK2OhKtTLjSRykWRJe1Fv+BQTVwyRD1vHhEtqwGp1Au8bjdYytEqyN0QrFITd3F7 FrlYbFosZJvYpwxzuBC8zijt0y0OpC70+F3SMtky/eCCFbICcTbkd3+g3feQcu/hehe/ hqMQ== X-Forwarded-Encrypted: i=1; AJvYcCVnVGbBcqxcxKxT0ax35gIFgT+z0treOHJS8ImEFvwib2OEBudDciLOF+buK3HHnFFzDX1HhM7t9TAO/MsbP0B0y1U= X-Gm-Message-State: AOJu0YyCQGjY/FvHn2Y2RiB0RjCeYBNeAAzSgJmQ/nYUZH5Bq3feC+fl kUt8Um0g+zExbCleeHsvtYS4r8wSSk/F7H8mlWTqSdXcpckCvr9B X-Google-Smtp-Source: AGHT+IFKcW5a3vbDFmwP3DxPZ4koAxQn8UX9fetjOQaD25naVYInhWkj9CS5TI6qwFc5sZ4mP8JJKw== X-Received: by 2002:a05:6a00:2710:b0:706:74a6:b1b3 with SMTP id d2e1a72fcca58-70674a6bb95mr3119562b3a.14.1719165580882; Sun, 23 Jun 2024 10:59:40 -0700 (PDT) Received: from localhost (dhcp-141-239-159-203.hawaiiantel.net. [141.239.159.203]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7065ca6a47asm3812653b3a.66.2024.06.23.10.59.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Jun 2024 10:59:40 -0700 (PDT) Date: Sun, 23 Jun 2024 07:59:39 -1000 From: Tejun Heo To: Namhyung Kim Cc: David Rientjes , Andrew Morton , "Liam R. Howlett" , Suren Baghdasaryan , Matthew Wilcox , Christoph Lameter , "Paul E. McKenney" , Johannes Weiner , Davidlohr Bueso , linux-mm@kvack.org Subject: Re: MM global locks as core counts quadruple Message-ID: References: <07e7d078-0c9d-6a1f-1ab5-295f86974b72@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 47750160016 X-Stat-Signature: p4hd6gskm5zzmeuewgxcjm6nhsbzd9g9 X-Rspam-User: X-HE-Tag: 1719165582-381881 X-HE-Meta: U2FsdGVkX1/a7qOtYVZmQyMTQ2cVGuX6tvid3dL95SbEOYWOxs3STy+qr3KBdrG90aVzAtLEn1OpcVrmdkUgqgTdWKpe3Pq1HvUAU2XWE/FbSQQCw+JNR2dKLyBqCSmrv/S1lrNZvZGQA2Ub78mYU31XhYhTtj8RU8V3OS/JaM36WGFFJDWSqKEH4styX5ZJIdxjPyRpkUanAU9JVe3aaXsVYiX2TZnY/y5huFI/opx4DPfvxKSeFKMGD5jwkvdtJ3B8ETP32BGt93fvmoxBU7//4eZ0FIN+jhvkIeKNGvtmjq4QWUfPkLNgIAUrwq3URHDRdWN2OW/gkh3aTdOooZIZMc6tthiNK1VmDLAzScZMxdOZJLUhy11bzUH6smjegQMsurKIJctHP3gcOeRedTGs1TEGd18a9E6EP/fNqjgjpQJVuFHDYbllXTD91Ukh4XxxoYu6jxIXmYCnYs2toOfzF/zd/64r/CPIfZrLc0wE6UQnGMkzQWGT+BrUvU8M+vemPkA9nOSTWwUx94a69ASspntX1t5JnjS4lksEbKbGm6RdxUXaJe/AKbzrElILG8vFuHoqqfJ6ambyS2nXO6opubuILrYlMcfi+SvwhW9wLG9A259KRBo+/gfiTY3CY3KliZLDvzr/QPEtDIwZW/Y9jOy/j3rU42FPBregElKVzvBdezyAcSQL9UvdcitE4aSassPNT6SIUjhC9ubCGoLv85V/akYkSeeux6VbIMhCA+KbG/d5nVrxbGZ0MrGVvIOZ7xqft1utROloei2BrTQXu4rEbQvTZjTM08+Qalz56h46wN2yZSIKS3sfbwahxiXn0qEqJV/uXdwv7wDs6gN1Hr9Uu66QwKO0Wxu8pRPQSEa5YqqgMSoS14kxGfQLmQcBuDs7MwV/KtJXjFzWBkSc8x/srRzTD5RxtZEo0MEfA2nn4xpYlkBPWDcYNjTj9L1SFRm0dEb9LWPLOr/ H7DO/we8 dFjM2qKVd9mqgdnJx5YfqEDdTeNr5sO9q/kXFeJ1v6EHDmpiE+ADFK+695b5wjkoPAq50qhSjNv4hql8XjK66Fxwu/G9tY1f3Twz2JmUn3undykkLBziWlC9czNaTM4/OV3+SCE3YXdHAq2URFibFMJq4ZFqr9w6qRe9nHQEYRtI8QgUa+Ot95ObLf7J7cJIzWEbX3jkAo3KBbMpW2jGh4vYW6L63RaHOZ4lz/jexpM7nzSBqTb/VaiL0E4ONwyoXj3/0TaBCZyu3H2wjMjDTZqFOajrsnoTfEI0PblomqQCRZwt6nlzqwkfjSR4R1WBkKFTcpsXRD3/0E6gUVm6YM7DYtfWFfTCd5SPXhQcvea0Pl2CiANHmIeHyfPTm2gKZkI5FFsriFs+33WVuOzOQ/ysXDcdGtyMyt+SCl3ZsLDgRL41+cZ+LijnF+M0qIA7+FEP+ 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: Hello, On Fri, Jun 21, 2024 at 02:37:43PM -0700, Namhyung Kim wrote: > > > - cgroup_threadgroup_rwsem > > > > This one shouldn't matter at all in setups where new cgroups are populated > > with CLONE_INTO_CGROUP and not migrated further. The lock isn't grabbed in > > such usage pattern, which should be the vast majority already, I think. Are > > you guys migrating tasks a lot or not using CLONE_INTO_CGROUP? > > I'm afraid there are still some use cases in Google that migrate processes > and/or threads between cgroups. :( I see. I wonder whether we can turn this into a cgroup lock. It's not straightforward tho. It's protecting migration against forking and exiting and the only way to turn it into per-cgroup lock would be tying it to the source cgroup as that's the only thing identifiable from the fork and exit paths. The problem is that a single atomic migration operation can pull tasks from multiple cgroups into one destination cgroup, even on cgroup2 due to the threaded cgroups. This would be pretty rare on cgroup2 but still need to be handled which means grabbing multiple locks from the migration path. Not the end of the world but a bit nasty. But, as long as it's well encapsulated and out of line, I don't see problems with such approach. As for cgroup_mutex, it's more complicated as the usage is more spread, but yeah, the only solution there too would be going for finer grained locking whether that's hierarchical or hashed. Thanks. -- tejun