From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) (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 9DA7838E114 for ; Thu, 26 Feb 2026 07:06:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.66 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772089580; cv=none; b=ZYoz3XFWNujnxiQSRdehlEGAkTEK+ZfCfyJYMKT8+S0fa7DPvbURE1hTtBLX+ZK7PbAZTLd2IW+Q/aOoA7uaWqUWa0KCuExGIQDe2Edyf57/yYqbSRfzmKLXeZkBwKxcikkuHaKiVgZkYFTQS/L73it3Xct63MEJnc9zdqcuOB0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772089580; c=relaxed/simple; bh=FazkpHjrkb8zZWOMtCUGeCY8AxmBQAe8akNPIgRMSz4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GyqDxFkhBZkZvfbfmwuzb5JJ/wqM9PqeA6zIYnaeDcVkA1SENLBqMT/mv4WJfuvOHeXxPJxXc7oEZ+Wzs3nNC6WSIq2MfoeLn7Np2dOBTeNPZXuEakse/sopmbAHmqPjXrXjei521VTIMZ6BARBgGolB89eDwbWVfz2ksjwdunA= 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=MM9fkwvl; arc=none smtp.client-ip=209.85.221.66 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="MM9fkwvl" Received: by mail-wr1-f66.google.com with SMTP id ffacd0b85a97d-43767807da6so305869f8f.2 for ; Wed, 25 Feb 2026 23:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772089577; x=1772694377; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=wRNHYTQlLX9EerVe+YBMUcaaqn9OJCKpaOuanb3o058=; b=MM9fkwvl6HuRz3VnxAR21CupoCPRAmv/tV7IRSuZQpy3oqPU7nra1jkW/mw4R7MeTP tOeUfnePIo8vFQI4U7sq7t5w1ZZunpEd8DTgtBcygSHSTBCLXrAGm+dMiumRZmAoPz8s 0BsKkWgutbfp/wvTNm3a5Ip8guGsQt22Te1lIWtDfz7Hqe/3r2tuADKgAhdmZKmrfx+G 6aYKOV1gCYSNx9NwJVfECvDSQAZV6bVzskZXvaMoP+tN6KfZDRnNaDxEunVrdVm9AL4M J49XZwTVm4gQYX/41mp/n1QmK93mH+IjAs4p1M2dvTk36k2Q85fiWrFVQIHGupDqPVL8 RnzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772089577; x=1772694377; h=in-reply-to:content-transfer-encoding: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=wRNHYTQlLX9EerVe+YBMUcaaqn9OJCKpaOuanb3o058=; b=HlU3MnhmXLHpJ5Ati4E6xkQJfIpAtuZaC9fEDIsRO33J9C8QRfepOw8pCESLiTerx5 CiQkdhX8IWeJa+PCaW+PYQsQ2CCfMR1TnGHm9ULfcem4VaTCZgB1q06DIKT2yzWBVZ6h iBxsVJajaaeIxmDj/w3z/nyHjDxEGCvTiPS+M3CO4kXu+7cc7W4zrXQtAYRyzWePQwXG gSkW3sBWkBsBk+PcOqKAu/3HMYIER/XKPZCXWiQxVYstiof5BUZeGbHJpOsRM9lcKZuu VCN4fGUDwNXCihOxFfBCRml06MKJpe4tE9Tjvs3qOv3rStG9QAVSgVnlNGm9d7HBLvk9 EiOQ== X-Forwarded-Encrypted: i=1; AJvYcCVinHnNs7qAzgFhdsboCa4DxFMrQNsfN3w1hSySeQ/AtqZCTwot2yXiY9m/lyPpfePUJYrN06VvZTR/SrI=@vger.kernel.org X-Gm-Message-State: AOJu0YxlldtRjy6Iq83K2lTGUzVFCguydtkfKpmqMM4X/9Hbm9oeJXd9 dW3sSzXewFI1hThLbdTrZ5FoA0DJ4RILxkEMkrZVjVjxiZTmYkhYajLP7VwwLXS6xPQ= X-Gm-Gg: ATEYQzzgChnfvFc9F4xzJM5qWkxVq/7W7+2vhCTNeTRk8f7nVl65seIlmEwlj/dW9wQ YIB8fNRfQMscl6qpbEiM37+7EThdiEr1rvSbsnqxLOWf2rA9FzID2d/FvkvRFk2QyHPyi48PwnR 6q5HpetGc5fPv8nObNr/Cxjqcw+HwxpqK+W+WYlykAiLaoJ6MNK+X79wF7WRxf7ia4IFClxF1/h tWhZWM5ASg+CKJ10zk83YWU9hOBNIBekk4oFzUeHVhjibW1+3WqrfzJxF/dHouqLH3odBiv8/AZ GYONkcVvn/INHX58G743TkFm+PYVQ2yz7akaMhgyYUHbAsQQpxCTyr9uGYovDx8nR5tOVu6PNqE Pftc7GT1MC7MzrCwK+bpJ3EoaJWufAgpa7M7Z4fDte/ssyD7YgycbfnvhLDR3C7VWyxAN6eX33k oKABDufa5FIuLHtcVvg9+n+8On6otP/7Ouwg== X-Received: by 2002:a05:6000:250d:b0:436:30b0:759f with SMTP id ffacd0b85a97d-43997f341b1mr1907374f8f.27.1772089576879; Wed, 25 Feb 2026 23:06:16 -0800 (PST) Received: from localhost (109-81-17-39.rct.o2.cz. [109.81.17.39]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43986aa2f84sm17021783f8f.7.2026.02.25.23.06.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Feb 2026 23:06:16 -0800 (PST) Date: Thu, 26 Feb 2026 08:06:15 +0100 From: Michal Hocko To: Frederic Weisbecker Cc: Marcelo Tosatti , 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: 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed 25-02-26 22:49:54, Frederic Weisbecker wrote: > Le Tue, Feb 24, 2026 at 02:23:25PM -0300, Marcelo Tosatti a écrit : > > On Mon, Feb 23, 2026 at 10:56:15PM +0100, Frederic Weisbecker wrote: > > > Le Thu, Feb 19, 2026 at 08:30:31PM +0100, Michal Hocko a écrit : > > > > 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. > > > > > > Here it is: > > > > > > https://lore.kernel.org/all/20250410152327.24504-1-frederic@kernel.org/ > > > > > > Thanks. > > > > Frederic, > > > > I think this is a valid solution, however on systems with many CPUs, in > > nohz_full, performing system calls, can't there be significant increase > > of lru_lock contention ? Consider 100+ CPUs performing many system calls > > which add 1 or 2 folios to per-CPU LRU lists. > > That's more a question for Michal or Vlastimil. And practically speaking we would need to measure that on real workloads to be sure. Keep in mind there is still batching going on. We just flush the remaining of it on the way back to the userspace. -- Michal Hocko SUSE Labs