From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D0C072F5A1F for ; Thu, 19 Feb 2026 19:30:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771529436; cv=none; b=P5btdHezTyhwtU4HENoO+XrDJ+OV/BHPEbHbPh3/9gioYquyLV5/14KE2GIHCYq23cgeTnT8NrFm+RtMsmTlggcvlRbMMuMtKbgXQLHP6fc/5ug8kCM2ki9vkadMhyzSOnW0qvzF1Rpvv3+ZnTERXBrazmmjXuf6F223pjowZ+E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771529436; c=relaxed/simple; bh=gN9ZUsqQrSAI3cyJyrV/V0WAlQclpKMv03oAD7EgttM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=R2Bu5JgZZVpIOGZ/AsrtoP7qQShQTiF4f+CT3bcvpIp1mlDrtm8AQUtX78TKrmy+81k2eb8kajwQgsH7oGyJ8aqYf+H+xJX9S/2UwMefuDfoLmKvWccpIl/g8Kd8I4SP2ue46YhAmWvQT6xwhXdQESStxGn01xWZrkBOtGXtLkI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=d3yuVqKb; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="d3yuVqKb" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4836e3288cdso9157065e9.0 for ; Thu, 19 Feb 2026 11:30:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1771529433; x=1772134233; darn=vger.kernel.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=bkc+W3z7LdbV7qOK0XaTDRftTDho1sOCxk9yc12rgDA=; b=d3yuVqKb+SJxvzuxkBreHupWw50rqKNwZ81xxaGToPOVvc9VxoNqk+DG6zeW9eDFVJ mdFLTCTD5nx6PaoZZkSf8PIuaNBtKuyA7jk9ydEpWBK7Id8py7JOjamU/rqM6stZBbH/ DXFsMPrRA7H6HaytAymmQPGFnrcI/OcpL7ND5NZSrgDdPBBxQA4yC7unNmVKv2B9nbeE 27cgyj+iQhWxX5weRmdxjGaAtHXuIuhLbSAIcRwQWsAeamrSZsdRMCSpyHrdMo/mN0l9 iSvb8GgbmT1n4cpZUKU/PCn9QI6/At2NpIys5j+6cbE7VGCvEfCEps0azxR4A0P+ddQL qEag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771529433; x=1772134233; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bkc+W3z7LdbV7qOK0XaTDRftTDho1sOCxk9yc12rgDA=; b=km3Y3pgJnOMxUR6L6cZ6itRpZKvgIyYUT8hfY/dUVmdN5GkJ/8kQjgFM3mAqQKXMw0 4KmpyFWd+IucjK9DqSAdsAWqF4u02gZ+G27ANxUYokq/zcZ009eFRt6n6tdnZzlcjnBW +rGwjMdrHZWwI3C/tQ2RGM5n/crnc84GH+gJzP5ZJxxdCPiHlT2vfSI5AmZtjciFpyGg iArqCnLV8nlp7yQZhjEuUVuw0HcwuTRqXtvEIq1O+PanEN/MEA8kGNzragZ/LBfjMoP9 Vi0xvMF3RlUYuSU1rM4Xm/ltML9uvxPTXxOJO765zzbT8vPGTInyHdAYVhT3YI6XN+0B NB1g== X-Forwarded-Encrypted: i=1; AJvYcCViqwQwOit/izZwv1wsp0rrByFFV80F4pY4CRlPp+Ae67KvpxeSDq3xFCiZUh6h53hcFjXg5jTEQeXoO/I=@vger.kernel.org X-Gm-Message-State: AOJu0YzeNnLs8bqAWmeJBFdDhzmwQ+b3EU1rUnCtqfEtKqWv9BjI9qgf wqfOw24ffeqVejRImbmGG3AwgajdFczmMnktBydv/j8Iu6e/irxE6OwoCjWZJEq+JAI= X-Gm-Gg: AZuq6aIkle5isnijuDiUXNEJef7xmRROXaGDrkuxQivcDHEAe89Sa1E+w8nRL3ok10D 4ZkYKPDAXeaXX0rMmx7L1u44YMp/MeINNVnf/ikjlewdjq2CzRmX95EUJu9ZgGK+g/DN+mR3XXE lcGKv+PvzJNA/KVDMMhe1w/whI4HFR1OABT818ddrggtXmVdD6Lqa8gWuW9xnIIkgNRNgdrkdPA oEKnk1jyk2XUNsmlWiEghE54mlqv+ErN950USDglAti4Xkkdxkgh0ZaKELyF6NCQRMVcSx+Ae+9 U7pAo2gX27dhNxFip5gGunDeV6guELZfmp4MPJqFMnuoQbhrjs5S+FfQCPeihY0tjWERrZm6Zpp WKMP7o0BBXFbt5hahoJy0w3nkErVPL0IBy2ScOiDnsTxddoYuV2f1/KN9rr51zI32Vu0hGjSK30 WUa/i9Nh/WDvOfOvlE8OhE8qYEfmImp5c= X-Received: by 2002:a05:600c:8a0a:10b0:483:a2b0:d210 with SMTP id 5b1f17b1804b1-483a2b0d22fmr25084335e9.7.1771529433119; Thu, 19 Feb 2026 11:30:33 -0800 (PST) Received: from localhost (109-81-84-7.rct.o2.cz. [109.81.84.7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483a31c56d8sm36582425e9.8.2026.02.19.11.30.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Feb 2026 11:30:32 -0800 (PST) Date: Thu, 19 Feb 2026 20:30:31 +0100 From: Michal Hocko To: Marcelo Tosatti Cc: Leonardo Bras , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Johannes Weiner , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Leonardo Bras , Thomas Gleixner , Waiman Long , Boqun Feng , Frederic Weisbecker Subject: Re: [PATCH 0/4] Introduce QPW for per-cpu operations Message-ID: References: <20260206143430.021026873@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu 19-02-26 12:27:23, Marcelo Tosatti wrote: > Michal, > > Again, i don't see how moving operations to happen at return to > kernel would help (assuming you are talking about > "context_tracking,x86: Defer some IPIs until a user->kernel transition"). Nope, I am not talking about IPIs, although those are an example of pcp state as well. I am sorry I do not have a link handy, I am pretty sure Frederic will have that. Another example, though, was vmstat flushes that need to be pcp. There are many other examples. [...] > You can't delay either kmalloc (removal of object from per-CPU freelist), > or kfree (return of object from per-CPU freelist), or kmem_cache_shrink > or kmem_cache_shrink to return to userspace. Why? > What i missing something here? (or do you have something on your mind > which i can't see). I am really sorry for being really vague here. Let me try to draw a more abstract problem definition and let's see whether we are trying to solve the same problem here. Maybe not... I believe the main usecase of the interest here is uninterrupted userspace execution and delayed pcp work that migh disturb such workload after it has returned to the userspace. Right? That is usually hauskeeping work that for, performance reasons, doesn't happen in hot paths while the workload was executing in the kernel space. There are more ways to deal with that. You can either change the hot path to not require deferred operation (tricky withtout introducing regressions for most workloads) or you can define a more suitable place to perform the housekeeping while still running in the kernel. Your QWP work relies on local_lock -> spin_lock transition and performing the pcp work remotely so you do not need to disturb that remote cpu. Correct? Alternative approach is to define a moment when the housekeeping operation is performed on that local cpu while still running in the kernel space - e.g. when returning to the userspace. Delayed work is then not necessary and userspace is not disrupted after returning to the userspace. Do I make more sense or does the above sound like a complete gibberish? -- Michal Hocko SUSE Labs