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 2AC38C2BBCA for ; Fri, 21 Jun 2024 02:47:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 783F58D0123; Thu, 20 Jun 2024 22:47:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 70A628D0111; Thu, 20 Jun 2024 22:47:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5357E8D0123; Thu, 20 Jun 2024 22:47:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 327158D0111 for ; Thu, 20 Jun 2024 22:47:01 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D203714076E for ; Fri, 21 Jun 2024 02:47:00 +0000 (UTC) X-FDA: 82253358600.16.D9D272A Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) by imf28.hostedemail.com (Postfix) with ESMTP id 22943C0004 for ; Fri, 21 Jun 2024 02:46:59 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=iZl7css7; spf=pass (imf28.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.222.182 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718938006; 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=XYmNom8Z2jihPjkLP85HQhWoftDrZ7lwEwgPQtH2N8M=; b=LH0mMKRV84Iks/+p9DpbjKVEWi09nTwWSGRJ84HR0b+i+pdWohIJusx15I/waMzZ2JL+xI oefUgJaEork5sWOoFym3q3uSsrJ9+umYPZ/OF0mTCHCUwCpcXQzrG/wMPFW7yuoT+1mJEN 4SDSdt9WM2mapDy6ISXFBpIkp6Y7MCk= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=iZl7css7; spf=pass (imf28.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.222.182 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718938006; a=rsa-sha256; cv=none; b=LJmq2uLPPVOEd4RA6ZuKB6JsyUmpGyXR/a8VySQFbcezKHpNQSfQWE3yTiZxBYs/boJElN fuPVu6q4Z17eap6xGAM0W8tEstJJV1E+Ub1+A5QpW878aKheOArchJsUQYPo+YssIRRHNM uLLtlAZTf87SnIgF+CL32YFFY1+MEMM= Received: by mail-qk1-f182.google.com with SMTP id af79cd13be357-797fb0b4832so90448785a.0 for ; Thu, 20 Jun 2024 19:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718938018; x=1719542818; 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=XYmNom8Z2jihPjkLP85HQhWoftDrZ7lwEwgPQtH2N8M=; b=iZl7css7dYF7VDbZlwoNfc/l1Xod9tsPRNKteZhKpmf/yT5yoopTPEiM/i6PWoQ6Pc ZoBblN78EN/AWtCuF+T0HSjKb0bSGGMcv7NV9Q6QURQmAFAda9HtjOvJFrDzwryldUkO C792unXuQoR5oLWvvkAkXttdvnHAtxbLX4hzi0PSLjcXg1dD2ZrHVrzBeoIuqnFpiCFm ZnAc88M/x/UNOBqadfOW7VtcYTTQF7TM3q0sLqMYkrcQlhJ6ssp8xeLettBIwiUeF5/o qKGHR8OV0nwFngu4Ppv5/Os9Ig1PbS4InB5HOMkDEubh+FrB8WRsl6FUxNmwi3MBo0gy F1wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718938018; x=1719542818; 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=XYmNom8Z2jihPjkLP85HQhWoftDrZ7lwEwgPQtH2N8M=; b=EHJtzH5k63BH0H6UfbCI0+5mjsWIIliK2seoKlmRVwoiyKoLCHSwvqky08ewJsQN0g 84IKSHaYZQ0+arKG92DTLpTedeyue9ncsArbidjHhJCVpaDQ+7paKTR6rasHjNUbQOQg 2XX+8S+8ZPq4rTHku95kkeI4HP3OP++8oS6U/4uUC7JfKQexuGURLGx3XFlLip4lrBrG Oto+Em7f1Fr0cJSWDsrUu31EmZj40Mg8Oibrlb3Us8wrYJ3YxJnOZw+qQa8C+LDA3pGl pSktoSBxRnB4elb/HEi0xZGu744BhWsvWNQOt46Q+uepgccmq3FFzABUMw6M8PJmYVtg UDuA== X-Forwarded-Encrypted: i=1; AJvYcCUtYlJN9odnY63PyfMoc+M20Xr64wlQEEmK9cYlzcYJ6tPMve5eTswiU7j6tTU4f8QKOLIecZJQTyHj+nYdX138PRo= X-Gm-Message-State: AOJu0YzYjV98YiQPht3J49W16NjIyYjIkhju0SYp4wReoZG14RJsidyx ltTvJJxrCQLx7A6mLgOfJBRwFpRXQWijKxBY3IgMgbVj7ZlNPz8p+Ba8dBEDzjEKJiJ116EQVCk 8fZk1xR7Ez4sdFuxDYdej2/ITwZ0= X-Google-Smtp-Source: AGHT+IE31uD0SaZ/p9ybFLAxFv1cb2OB1DdkoLZnjSSyxe8MMRXPu2w/3oCG89iYQfNSpLBIIv4bAEaYllTj0BMd3g8= X-Received: by 2002:ad4:5881:0:b0:6b2:deb4:ee55 with SMTP id 6a1803df08f44-6b501e4e454mr70110846d6.34.1718938018184; Thu, 20 Jun 2024 19:46:58 -0700 (PDT) MIME-Version: 1.0 References: <07e7d078-0c9d-6a1f-1ab5-295f86974b72@google.com> In-Reply-To: <07e7d078-0c9d-6a1f-1ab5-295f86974b72@google.com> From: Yafang Shao Date: Fri, 21 Jun 2024 10:46:21 +0800 Message-ID: Subject: Re: MM global locks as core counts quadruple To: David Rientjes Cc: Andrew Morton , "Liam R. Howlett" , Suren Baghdasaryan , Matthew Wilcox , Christoph Lameter , "Paul E. McKenney" , Tejun Heo , Johannes Weiner , Davidlohr Bueso , Namhyung Kim , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 22943C0004 X-Stat-Signature: jnmbnf91aajhut46kr6m38kkecpdj36q X-Rspam-User: X-HE-Tag: 1718938019-437756 X-HE-Meta: U2FsdGVkX19H4la5K3Z0AAxiTXzNIOgtn27t8FhK9NoYNJLU1MnwWAZq/lt9RmAL0ABQIP0wPFa7AYJL958vjcK1TIjeYWZERnCZomJsv2ZYm/ZZUfH+A3IHfSvwpbzaeKWvhmOeY3ouLlm/dRzFnxdTN20NOPhgWMsBVfNXwFH8+0bTeR7pClO0APev5YZDapFQ4Geh7vWQhfb0qyW6twNPQa5M3OQb5Gl+hm7TUoULe5an9hQ/ELBOCMyr6lapnDbaHh/LqvzM8shoY4mZ8FOH+Y6vVOul5/IM0271dr+wmwdKFGG0IwRNPRo4FiLCKIuL6V+S6MhXCFPBTGaH3OeSf7z6xs+ODqCOL3TASPNZjADZoYTh8zLJh38PNqng4unCo8QTFquDefy7IsE7Kk2uE+ZnDOwuCOrARdmgowYCBP7rbGi3aNmd3W/4ADePXid/VR4uE6Yiy17Kpd5C/mBKn5s+kbFHnWh0g/5jueW7LO1SE8mSEKtjHE3Lw56xIq6pgVE07uqgLrTTMRXJ7b5UKU0U6mQPHpAeFh37ULy2k7pztvj56AllsQ+oPLZRsANMsT58S/o82/pO6/qB+Z8LeVIisjl/X3BjqRYTRBVl/qqvm1cOzljf2WIpSXQ7UTl24jknOvloyrh9XurFVg4BpfhO2QoYH3+DjZqCUaPcvKq5h/uciCSRhphaETTD9S1efP/7U9KMxxYEceneYGq0kXiLsHJN0d4W3dP9kCPqDNaug4yogEr4M/LqIszYFGo7rOn/fqFqvcXItkDWELrc/UuXtlxKm5/y+i5qjte37mrG4KauJr6WSNsqjWM0bSlgtREEQPXHSMlZYEKq2AiwN4lcAfA2hN3TmOh9XZfx/CTjfpEFmOuW4WQ9b3IYpQq9FsIFRS30nmXbMC2z+ZDwAWNazip/iOaiOUJx6rgjW+b+sf45fgwtvNJNaSpy9lPoRvxVsJoSTQsbct0 SHsSvlt8 fveIRZXfqsxy9XjWl3pGn66TC9TB28ZGPNz3AVI9pLI0K4dw5qCPaOCOk3eickb+0ofFfr/r/P/EfujgD3Q7OczVgPUbanay8GHp9tVt4T87jFXL5nfb4JUOJghpv9gjoAMiqwNhE+/nh4ycrF4iN1Twl4NnLGf/YcWbeba6QgyKcUAhl7lNBE8GNjMX8ZcvNTXhquwDBKNtqcJdDZ1fdP/hA52Iz2p8OGo+zyiGVBblzZJ3ZLmSthlQ6CKnm330QkFrMyYKCPBogQAAmfM7O6v4l4/AUT0zho5aPCrDDSl+/dpMn8c+g+5JJrWVeN5pSStv+hgim0EFgsRqhG5OwQfkW6H9uAMtXdrfntnmb0ymrxsS2X32GXsttH3DX8nNaXvSLjyB925mJwuaWzmV4HOMgEwcq0DrnRoTGU1k3qTypa6XXP229shFIAg== 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 Fri, Jun 21, 2024 at 8:50=E2=80=AFAM David Rientjes wrote: > > Hi all, > > As core counts are rapidly expanding over the next four years, Namhyung > and I were looking at global locks that we're already seeing high > contention on even today. > > Some of these are not MM specific: > - cgroup_mutex We previously discussed replacing cgroup_mutex with RCU in some critical paths [0], but I haven't had the time to implement it yet. [0]. https://lore.kernel.org/bpf/CALOAHbAgWoFGSc=3DuF5gFWXmsALECUaGGScQuXpR= cwjgzv+TPGQ@mail.gmail.com/ > - cgroup_threadgroup_rwsem > - tasklist_lock > - kernfs_mutex (although should now be substantially better with the > kernfs_locks array) > > Others *are* MM specific: > - list_lrus_mutex > - pcpu_drain_mutex > - shrinker_mutex (formerly shrinker_rwsem) > - vmap_purge_lock > - slab_mutex > > This is only looking at fleet data for global static locks, not locks lik= e > zone->lock that get dynamically allocated. We have encountered latency spikes caused by the zone->lock. Do we have any plans to eliminate this lock, such as implementing a lockless buddy list? I believe this could be a viable solution. > > (mmap_lock was substantially improved by per-vma locking, although does > show up for very large vmas.) > > Couple questions: > > (1) How are people quantifying these pain points, if at all, in syntheti= c > testing? Any workloads or benchmarks that are really good at doing > this in the lab beyond the traditional will-it-scale? (The above is > from production data.) > > (2) Is anybody working on any of the above global locks? Trying to > surface gaps for locks that will likely become even more painful in > the coming years. > > Thanks! > --=20 Regards Yafang