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 15F82C2BD09 for ; Mon, 24 Jun 2024 22:54:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 87A206B0136; Mon, 24 Jun 2024 18:54:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 82A3A6B015A; Mon, 24 Jun 2024 18:54:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6CA886B015C; Mon, 24 Jun 2024 18:54:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 4B53D6B0136 for ; Mon, 24 Jun 2024 18:54:54 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id ED01DA146C for ; Mon, 24 Jun 2024 22:54:53 +0000 (UTC) X-FDA: 82267288866.18.8609921 Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) by imf19.hostedemail.com (Postfix) with ESMTP id B9DF31A000D for ; Mon, 24 Jun 2024 22:54:51 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=flAMX3b4; spf=pass (imf19.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.210.45 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719269684; a=rsa-sha256; cv=none; b=YFTQZCqE/BPZHm+chGqmSYY8Puux2J1aBrXqOgJJNg9cYYeR+TQt32NLteeBp5z6oHuScI I91IGrdaYzhmLswjGhgO6pQTjTK5eGBKUeHASCRKgFqm7eCpGNGuHF1MGIfQMe6nqeRwGc wVNEtu4+LtGB/wzmCELXHeQvucF7z88= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=flAMX3b4; spf=pass (imf19.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.210.45 as permitted sender) smtp.mailfrom=boqun.feng@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=1719269684; 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=RmrF0dTmcOIfg8IkJIqr7iTWstwct6FH7y6vme7yHSs=; b=By/sdgSiPbDkifEtLVxhqeWc6D0XwFjHr2PKqI1iZzwr3ItrqelN4EGXTGMYzrATLh17Pk GYG1ySjFYI60lZV57IojemlMVvy8IzbsdBbsQiKQJAcXd+GTRbXhL6F1O1gXKN7drQZMQi /PMHZRh01c7xbOmZrhzyQgyJVjZxgZA= Received: by mail-ot1-f45.google.com with SMTP id 46e09a7af769-6f855b2499cso2663526a34.1 for ; Mon, 24 Jun 2024 15:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719269690; x=1719874490; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=RmrF0dTmcOIfg8IkJIqr7iTWstwct6FH7y6vme7yHSs=; b=flAMX3b4Qh5hzBDNMkKKKqe5IQ7zU3K93qkfExMI6CMMGEcD2cWFLha5kOjaujH7+n uGnz+E2LpW2bAg8R/ASoAqIqK2xmoLcqxwn2kmTPm8DU6EahUF5bNrtP2MbLde7kxBrj 8HcwToNMZs5qAYHZy1UTV086/wqyJT+ZAash1n96wYPQp/iINreYwP2Wi28QOfI3lYdA 25RCMFnybILcEufhEYNr907rsuAAcCTn8rFDxY36Q25qk6ILWoCbDOC1dssHiUcrT64s uzyAGALr5lrFJR07wzNl10aShMvU/JIbuKWRuc5xTzKt7+aIFBBuP2f3Po0OyLZ/ZU+O eKBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719269690; x=1719874490; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RmrF0dTmcOIfg8IkJIqr7iTWstwct6FH7y6vme7yHSs=; b=Vap3gd8Itd8Afi6iESoegvUjzfiGovGzuGpbb0/vp4ElSxNCW3WTavQaglQb2m7lJ5 DtpdZ7znZY+5xX3AfqRFalgvJJEfgUL0JKT8O795HfseFy1KhogfMHY4W0ON/QXN3ivP D1FCsAU8hwflsCKNqbXLzeo2bd/RwFki86I1/WMBKEEOsJQSD0HEHln6+jo/E9mRClWd yOMYKitIp/RGZ0vRQ8Lp6z5tsuYr0K50VFXfqTBB5znnjNXbx3e9+lceXlElwcGjxZ3Y KgsLXP7gwRjC4QRxVRCuxm3Zbzo2Op4/cMiXIV0kcwd9D0Ee3DC3R6ObPcoj5CLkppRU CxVw== X-Forwarded-Encrypted: i=1; AJvYcCWlWLzSz3s64qhefAcONXoPjrHJHlpTlCATk749H2pOicwzJtTkklWJGlENxp95Ky88PILFeQbXEeKTcPT59Bbot8I= X-Gm-Message-State: AOJu0YxCC3mzENoNy6/XwOgorO3JWChpLldbJjejK+maTKaOqZ+98kNZ GRjY4eadnnmskbeP8lmAPL8xlOapOirt97NTF0CpgandMpUMq6DY X-Google-Smtp-Source: AGHT+IF1LmdDz568NfaQSwCT7YStZy+hquXQ5WPIRwD8wqfSpoWD/xHua/MASQDacD79OmYmZMmJnQ== X-Received: by 2002:a9d:7b43:0:b0:6f9:62e9:9f93 with SMTP id 46e09a7af769-700b12a1d3emr6253705a34.35.1719269690460; Mon, 24 Jun 2024 15:54:50 -0700 (PDT) Received: from fauth2-smtp.messagingengine.com (fauth2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id af79cd13be357-79bce8c3775sm351009885a.59.2024.06.24.15.54.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jun 2024 15:54:49 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfauth.nyi.internal (Postfix) with ESMTP id F3F1A120006B; Mon, 24 Jun 2024 18:54:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 24 Jun 2024 18:54:49 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeegvddgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehoqhhu nhcuhfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrg htthgvrhhnpefhteffveeuhefhveefgfehvdejkeefuefgfeegvedtheegvdelueevvdeg teffueenucffohhmrghinhepkhgvrhhnvghlrdhorhhgpdhlphgtrdgvvhgvnhhtshenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsohhquhhn odhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdeiledvgeehtdeigedqudejje ekheehhedvqdgsohhquhhnrdhfvghngheppehgmhgrihhlrdgtohhmsehfihigmhgvrdhn rghmvg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 24 Jun 2024 18:54:48 -0400 (EDT) Date: Mon, 24 Jun 2024 15:54:14 -0700 From: Boqun Feng To: Vlastimil Babka Cc: Leonardo Bras , Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Thomas Gleixner , Marcelo Tosatti , Peter Zijlstra , Ingo Molnar , Will Deacon , Waiman Long , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH v1 0/4] Introduce QPW for per-cpu operations Message-ID: References: <20240622035815.569665-1-leobras@redhat.com> <261612b9-e975-4c02-a493-7b83fa17c607@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <261612b9-e975-4c02-a493-7b83fa17c607@suse.cz> X-Stat-Signature: m4zb3hhzoro686fs5optqspzimq48qfp X-Rspamd-Queue-Id: B9DF31A000D X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1719269691-340786 X-HE-Meta: U2FsdGVkX1+qqzm2PjQW9vbx655PnTueqzznZGOH8bS1JUP+iP0ySB61rrLwnKdZTf03/+vSgpLzQdEFppW9kWjQW3hlsS5RXvBi5cF6BCkUNGDNrNbLbZGf35tU0qoTBwl4Xtii42GzuIVEelapmkJ1jiSfhDC+Yvtsj3bCM1374Ayze9nK/wAmZ8rARhicrn9HDvYTOvR1pNdxFNG/fdSp476Kw1CSEgHY5NbZqQi8XS5SXzXuD/OEe2TRnR2kPKaU2jCuTiZdQhND/KusVKa429ZUiTECkRMLwco2/qOFMh1qJDyJ5/1a/K8WX5/4AptI/eiT+AngJCHX+a7RzWk880cgBNDlr5NP6+O9/AYBgXWHUi3hftZpA060bqlzDJq+3qd5dJSKdS7lL8EmvBnqZeyp3bche18iX9Mj9EUBh1T0tXY+eYOcV8ezPV4Gp6DbaE4r4oTqyI8OxokpRz2yUVk0SvBqsFY2+0LMe9rSU+0AZsSH4Z+8I4ZA7ENukmIM6QBAVE3ISk1FWrkdIGTapNvok9f0SZmgRtpZeZxe/FKvipMBtT2Gq6a+3KavKAJkQAnC5QlbwpJKeBGZu4iKROXEKrAu0tk9qLwvp8jn2xqWefg8xttcvwcUwwy07N9iebLCH26dgFuMyurDOpGcc3caODFyc6Zj93ov/3WVrU4Ni0XAQy/yOToRKOVK2j0AxGQi5oe2J6rWsbL2TtXGTRmmDCAsPwJ5RE2NPjajZEeUfvSSYo7V36xGMceQHHaK/Y4YOLTWQpBpL0xM71zjk+JEuHgdrhc2ZpOtESiz6MGay5ssOyFV6Fzb6tUGpYQZntc4l8q65pKRMSK+PrvASdnGTHIoFie9CPTaGac1t26YFdGV891xfF+smKXo8OiNHSGECpX+qho/FcjGV9RusmcgZYeGjNX+8JUeLqKV0RFM0TqcxlpI+7zCdzTI01neDY3Hjzkndiei1UK +3K9wybo eZ4kOKXDIFIaro6vfAiGTvqv9YqFTdbJaKzcz0Ku9wZX6UUyp8kf8J9xCdLnJVnB1QP4XCHfSsa7FxGGQ6RxWeeKYn28DYBlw0YglOL8FDbs4AtutZUlNnuPMMkMGsF18wZMAOfQcvYjgAW+AzgTiSexb92JwpfnDZM4FpZtbeDbyEP4rTtjZEwiagUN5eSvVV+rwLgaoNdcyYFXSuxVvR6qjZljhAp/doml2F4M0oRnVbm6Jm4l2izCGgq9cIYIlmrt2poX55e/hwi/2flVjmZ311MW43rPrbYZpNqrVv4wcWE1msEahbIBCnUMqK8rk0hV56ewKmaayrMU8c0ppGDL7xs9LEWMf/4uXDyUEF4KBNpKz/1Mz9U2EiMMEyLDusbnpY3OZocjbuBFhPE4emu+CSCUXe9oOrOLYUo1ZPbVoxB1FQJzcB42GS1uqSCxtvIuOlTYFZfuvymY7Oisn9yKQesob/Guc0ATqUj9nIkCwkWwn6a1syJi6lunmj1dWFNz6v+yP9+mkw6NNCWrySWz//aC52z9t4OKWZvST87olM9poeOXnAcXHIcaH3NcpgZoRlmsTohCrgNlYx6H6erRSfw== 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 Mon, Jun 24, 2024 at 09:31:51AM +0200, Vlastimil Babka wrote: > Hi, > > you've included tglx, which is great, but there's also LOCKING PRIMITIVES > section in MAINTAINERS so I've added folks from there in my reply. Thanks! > Link to full series: > https://lore.kernel.org/all/20240622035815.569665-1-leobras@redhat.com/ > And apologies to Leonardo... I think this is a follow-up of: https://lpc.events/event/17/contributions/1484/ and I did remember we had a quick chat after that which I suggested it's better to change to a different name, sorry that I never found time to write a proper rely to your previous seriese [1] as promised. [1]: https://lore.kernel.org/lkml/20230729083737.38699-2-leobras@redhat.com/ > On 6/22/24 5:58 AM, Leonardo Bras wrote: > > The problem: > > Some places in the kernel implement a parallel programming strategy > > consisting on local_locks() for most of the work, and some rare remote > > operations are scheduled on target cpu. This keeps cache bouncing low since > > cacheline tends to be mostly local, and avoids the cost of locks in non-RT > > kernels, even though the very few remote operations will be expensive due > > to scheduling overhead. > > > > On the other hand, for RT workloads this can represent a problem: getting > > an important workload scheduled out to deal with remote requests is > > sure to introduce unexpected deadline misses. > > > > The idea: > > Currently with PREEMPT_RT=y, local_locks() become per-cpu spinlocks. > > In this case, instead of scheduling work on a remote cpu, it should > > be safe to grab that remote cpu's per-cpu spinlock and run the required > > work locally. Tha major cost, which is un/locking in every local function, > > already happens in PREEMPT_RT. > > I've also noticed this a while ago (likely in the context of rewriting SLUB > to use local_lock) and asked about it on IRC, and IIRC tglx wasn't fond of > the idea. But I forgot the details about why, so I'll let the the locking > experts reply... > I think it's a good idea, especially the new name is less confusing ;-) So I wonder Thomas' thoughts as well. And I think a few (micro-)benchmark numbers will help. Regards, Boqun > > Also, there is no need to worry about extra cache bouncing: > > The cacheline invalidation already happens due to schedule_work_on(). > > > > This will avoid schedule_work_on(), and thus avoid scheduling-out an > > RT workload. > > > > For patches 2, 3 & 4, I noticed just grabing the lock and executing > > the function locally is much faster than just scheduling it on a > > remote cpu. > > > > Proposed solution: > > A new interface called Queue PerCPU Work (QPW), which should replace > > Work Queue in the above mentioned use case. > > > > If PREEMPT_RT=n, this interfaces just wraps the current > > local_locks + WorkQueue behavior, so no expected change in runtime. > > > > If PREEMPT_RT=y, queue_percpu_work_on(cpu,...) will lock that cpu's > > per-cpu structure and perform work on it locally. This is possible > > because on functions that can be used for performing remote work on > > remote per-cpu structures, the local_lock (which is already > > a this_cpu spinlock()), will be replaced by a qpw_spinlock(), which > > is able to get the per_cpu spinlock() for the cpu passed as parameter. > > > > Patch 1 implements QPW interface, and patches 2, 3 & 4 replaces the > > current local_lock + WorkQueue interface by the QPW interface in > > swap, memcontrol & slub interface. > > > > Please let me know what you think on that, and please suggest > > improvements. > > > > Thanks a lot! > > Leo > > > > Leonardo Bras (4): > > Introducing qpw_lock() and per-cpu queue & flush work > > swap: apply new queue_percpu_work_on() interface > > memcontrol: apply new queue_percpu_work_on() interface > > slub: apply new queue_percpu_work_on() interface > > > > include/linux/qpw.h | 88 +++++++++++++++++++++++++++++++++++++++++++++ > > mm/memcontrol.c | 20 ++++++----- > > mm/slub.c | 26 ++++++++------ > > mm/swap.c | 26 +++++++------- > > 4 files changed, 127 insertions(+), 33 deletions(-) > > create mode 100644 include/linux/qpw.h > > > > > > base-commit: 50736169ecc8387247fe6a00932852ce7b057083 >