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 5AE051D95A3 for ; Mon, 16 Feb 2026 11:00:59 +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=1771239660; cv=none; b=B2FU+FxA2w+Cn10vqWHwDAZ9CjetM5fDoMoCceP3z7oDD4pdYGO7LXIP8D64p7aoirNnP4GQ8Eolp2EykVTjDxr4HyJgnEit4KqeIiZU79HZKBlE7Cglcieju7L0935LdoP0TuYisH+zzJ2kJuZIDFRnoiUjya7mAEiaGsC9oTw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771239660; c=relaxed/simple; bh=5Bs2zOGo2Vwhwu/Eo9m6Z5+r8bQ43/BQ6C/GLcaCW1s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qyJ0/aRpIegKhTyGDFzqx02t6zt2PNC1M6dsuuJqGdsGHa+sL305mtdHfYD4Qalx9332jgL7yIy2XS3OpNc0R2LfT5uSV0WfoN7eOoe14cMeQ8Gu2azDVnl8xa81D/+vP2H8UTSSOydC3ILncEjpCgwodL0GPn2HmB7RwRGO/WA= 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=JV77inzM; 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="JV77inzM" Received: by mail-wr1-f66.google.com with SMTP id ffacd0b85a97d-4376c0bffc1so2287225f8f.0 for ; Mon, 16 Feb 2026 03:00:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1771239658; x=1771844458; 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=jzgolleu2SIxliK/vEtotu12nLOXFd4HqJviqi0SJ1s=; b=JV77inzMfmp8iSeJBoZIGRfsVA5QBobwKz+ofecyLBKdz2nuE1RlRs3WDFfcV/fMMA 05w2kRaV/Ii+EDWiFDZeURwU2KZTY24emo8ggMte2eIvjD4H7BTOhWkHZSIYQ0TlV2ql MZh3ydZzdFfYMffyPHnfSa0CTh6Xhepze+0ZWhHV2kHN3LKtYcEugZpoGhDxOV2ECMxR 5BKbzq2MtsOM8snELGOCDaGGIExCz53vXf5or5NynIQVj/zCJmlUbnV1xkKkv39ALNK0 6MBLrEYNI84Sq8StUT9XfD1vf6mxweZdjKgAEb2B4N5aWgq18ADXuyUf5bJCRVsmYRKn KM8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771239658; x=1771844458; 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=jzgolleu2SIxliK/vEtotu12nLOXFd4HqJviqi0SJ1s=; b=kv80c6cjqL/DYrad4F8Mz5p6a+CEWoPxWAWGIvZ6PMgqU3KEqc7GXvEJsF85I9hRUt 2LPelk9lq44dT7kHhKpk+C6oxOX65Bc0RMXlJoJS/w0BOKYgtShSY+95TxftUg2HjQvZ 46CMYOleSyGFWiTeDIgJsfpAU9keEQ81g3XRKIY4RV7yqcUH7j/p6w3kg7qIZjrUgHMs NV/zTo19/qbX/t8MIg5uKmE4BSaWUs3k9c576vcnUocRSK4Uwex0vqbhFvuMhn3u8Tk5 s+FfYcYd/8vjzJ+coIIy2gDThnVC+1QixYiS6mRfQ3UkOl6rIo7QYzrQ6sz61AqGLFzv eI4Q== X-Forwarded-Encrypted: i=1; AJvYcCUeFUsPBD2WNzIUeLTMHkuG83K8T3HAZExJK2bqlc+1f/Mf5ZwP5GF6tw3UrIeFxEJWN5b7uvyJbTlt9R4=@vger.kernel.org X-Gm-Message-State: AOJu0YwynR/S+ayXoieeOqzv4tdVgMu2YTfQH59am1JpGYtS7fTof83F Mb0L1yZalZ77yCsf9fGAROcXj3FssP0kd5qM6pVzO/o6dBbRJU6Rj/QCB8IuQbWgy0M= X-Gm-Gg: AZuq6aLvemcYBDhwaesTUkFgiCDFw+Q9majlRRKLoXcqrMXMeyHWRFCsfaqKe9UPqDc G/ip7r6Ha1LMEYPP6XgHuITaImDjeYcZN61cebiSrRyMJrXh082gZLkONTDxZjnYVJh4rmh4ZKB g+9zrepndGHbjRqLlqipV8Gf5MhUs+I3dKg3lx6xQAHbNO1KAnjosg1ibUW254kD+OLdjvkZYQG 55agc0q1FD6SsoS9g05Th3v73MXo6rOwjcmtQUXBM/0rNqmEN8jwyG3D7+rO6MDS+ESvdcy3M2Y 7pvHd+7LTtdF1qdVEUyMjGbtWFErCZPCitB+QQL64A7ZMIn2+W5bGWUTbt1KBNgBhps/DBXn6kT BCDk3UfmzIqBazVLGGG1znNy+kaEsz2zMQvYn+eEuMnC8hy9aTrUr81cZUjMBJOYIBqQYSRV7c4 rFvHllPJ7nGRdYOWf181+9nStKp/he98ncrNFj X-Received: by 2002:a05:6000:3102:b0:430:fdc8:8be3 with SMTP id ffacd0b85a97d-4379790ef6cmr18730047f8f.29.1771239657494; Mon, 16 Feb 2026 03:00:57 -0800 (PST) Received: from localhost (109-81-87-131.rct.o2.cz. [109.81.87.131]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43796a6a5f0sm25813158f8f.11.2026.02.16.03.00.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Feb 2026 03:00:57 -0800 (PST) Date: Mon, 16 Feb 2026 12:00:55 +0100 From: Michal Hocko To: Leonardo Bras Cc: Marcelo Tosatti , 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 Sat 14-02-26 19:02:19, Leonardo Bras wrote: > On Wed, Feb 11, 2026 at 05:38:47PM +0100, Michal Hocko wrote: > > On Wed 11-02-26 09:01:12, Marcelo Tosatti wrote: > > > On Tue, Feb 10, 2026 at 03:01:10PM +0100, Michal Hocko wrote: > > [...] > > > > What about !PREEMPT_RT? We have people running isolated workloads and > > > > these sorts of pcp disruptions are really unwelcome as well. They do not > > > > have requirements as strong as RT workloads but the underlying > > > > fundamental problem is the same. Frederic (now CCed) is working on > > > > moving those pcp book keeping activities to be executed to the return to > > > > the userspace which should be taking care of both RT and non-RT > > > > configurations AFAICS. > > > > > > Michal, > > > > > > For !PREEMPT_RT, _if_ you select CONFIG_QPW=y, then there is a kernel > > > boot option qpw=y/n, which controls whether the behaviour will be > > > similar (the spinlock is taken on local_lock, similar to PREEMPT_RT). > > > > My bad. I've misread the config space of this. > > > > > If CONFIG_QPW=n, or kernel boot option qpw=n, then only local_lock > > > (and remote work via work_queue) is used. > > > > > > What "pcp book keeping activities" you refer to ? I don't see how > > > moving certain activities that happen under SLUB or LRU spinlocks > > > to happen before return to userspace changes things related > > > to avoidance of CPU interruption ? > > > > Essentially delayed operations like pcp state flushing happens on return > > to the userspace on isolated CPUs. No locking changes are required as > > the work is still per-cpu. > > > > In other words the approach Frederic is working on is to not change the > > locking of pcp delayed work but instead move that work into well defined > > place - i.e. return to the userspace. > > > > Btw. have you measure the impact of preempt_disbale -> spinlock on hot > > paths like SLUB sheeves? > > Hi Michal, > > I have done some study on this (which I presented on Plumbers 2023): > https://lpc.events/event/17/contributions/1484/ > > Since they are per-cpu spinlocks, and the remote operations are not that > frequent, as per design of the current approach, we are not supposed to see > contention (I was not able to detect contention even after stress testing > for weeks), nor relevant cacheline bouncing. > > That being said, for RT local_locks already get per-cpu spinlocks, so there > is only difference for !RT, which as you mention, does preemtp_disable(): > > The performance impact noticed was mostly about jumping around in > executable code, as inlining spinlocks (test #2 on presentation) took care > of most of the added extra cycles, adding about 4-14 extra cycles per > lock/unlock cycle. (tested on memcg with kmalloc test) > > Yeah, as expected there is some extra cycles, as we are doing extra atomic > operations (even if in a local cacheline) in !RT case, but this could be > enabled only if the user thinks this is an ok cost for reducing > interruptions. > > What do you think? The fact that the behavior is opt-in for !RT is certainly a plus. I also do not expect the overhead to be really be really big. To me, a much more important question is which of the two approaches is easier to maintain long term. The pcp work needs to be done one way or the other. Whether we want to tweak locking or do it at a very well defined time is the bigger question. -- Michal Hocko SUSE Labs