From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (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 774682D8793 for ; Sun, 8 Mar 2026 17:35:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772991343; cv=none; b=cn4t2NFKZ3wQzhWIsKthMfYlCOffza1bbtdCflM8AWEEHG9KFn98U51O8QIglJFmqCwnXptb4yELZiK7iiiRUZ8hH8IAaOQBNDLwyXyn/ZoAnIoNwL+t2bTslXoL21JIhBGIFzaA3WZziUT2D962sbKNuW82lZtKWO3UOB0okbQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772991343; c=relaxed/simple; bh=lfme5u9LJhgQpXmyam5J21ORBf0gVxgKo+2SpDTNOvE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type:Content-Disposition; b=YwWofSlcFECLLLYWusZjP1CedUhfgCNPljgPMn7BWHa6OnAUUOyPQRLeRpKaChTGunfuezS+YLZ52NqkMMp7VneKi6jIM7yYKElhLefQ1gaoan3YUVtS4JkGYaLByb3WUQzw/n9SaIrBBtV9h2JVysxHi1JwthuHVGIOyKUtEnw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=htMWwVrX; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="htMWwVrX" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4852f8ac7e9so15424085e9.1 for ; Sun, 08 Mar 2026 10:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772991341; x=1773596141; darn=vger.kernel.org; h=content-transfer-encoding:content-disposition:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to; bh=GC8HMKQ4ZWxWCtuNOfqYbNHW4R2NaicK2jQPUUta23k=; b=htMWwVrXlktLsJApiKrI9nyH07vg59daTLd6NWPo6k+HvBKaXeGGIsialK4oSdC/Gz HHrMAyPLogDZVqtJFAZyI5UXdnsjgN89aVkrVo33WVucz3rvmujEyC93qxmsnQus2+a0 wOewmrsYQhUa4PnwozuzRYc7mq9StabLWldK2RnZc70oOnFbGgNYGmsXgqye6ahQLZ/O zXaZCS+70qbd0XN28i2vyTNOoto2fg3N/QpyBzCRMocTIVki/CqW8+Yywja5zgEHUvaU d1XmlZbr+L1h0lbllx7b07VsmNO7xWEpXs5bieOR+GDtBd+UStkaIIlYerPIdyBkf5ID FgUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772991341; x=1773596141; h=content-transfer-encoding:content-disposition:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GC8HMKQ4ZWxWCtuNOfqYbNHW4R2NaicK2jQPUUta23k=; b=n74O1Ep1kztnad41G/JpWK9kRxDFt4gHfYCFyiVuLFqIWu+JeVA+7fkT6vEXfz0RsK +Q1Zp8mbgogI2TBfD9ZPEKWq5B/4jfR9lJVaFFOwdeESEV8HDHnJs0bGHWrI5szL2RNB jPXZ/Y5nC+n9px6s8oqAyjC5v8R9yB7aOhvcQgIljakvuaFRAe5jyUA7whHGSkZp3AeW /eCkn9ABog26DqhJ3os7WTxlrhIC/Y53eWhWOcRRpgaIZdgWhawW1Hbg+QnkCh0P1SPj 8ae3V2rkKK84GTPvz5T1Lf6BvUFKpt/j06DUfP4FOvAL1ugoXsd38Ef49jKmQq8CojXk K3Iw== X-Forwarded-Encrypted: i=1; AJvYcCVRhKh3vKeamcsezT9hLEOJkyLcFzwBl2skYDC4hjjQMvlxUML4YMLMGtMnYYQYsxle1jaKRxKQe+sVc5g=@vger.kernel.org X-Gm-Message-State: AOJu0Yx+rKa5bE3dBXZNP3hvCz2iLbWoQKIKLKLUvyadBjqrbS+98hGe 9lMOVC4ragRB0cngLmWm3E9vNL3uEjA3HQeQPO+MFdWit04/fTQX1BUk X-Gm-Gg: ATEYQzwf2n4aXsNNj1mh08qmQWyGhKWbf7WAGKzyd1+6tssi0sk4NCtipH7Wh2TFiab iCatabxc++3q/jWeMWqmlQlqrfIQBfyRJ0LVUQ9MKHdO98Zuvmv0JRtYp6OlEqqP7ON1yWPNx3N +jBEBbGJ+Cb3grLitqkbZ6mQJy1Wb9G7KwCaEMRWGw5zoo0jWr16BGE/YK+0S9yAMuzSRbA7K0E ynk1z+ZiLLWlu2bBHg9PoeiGCDqteqUhWmeoKO3Mn9IElBLek9jmKcB9nZAm10ie5+ILqUy64Wn eLJbV4jZtCDu0C0VyOD2yrXE+qXHWxqMxrRhVlTyjwC38iihun2uHT/gSPyU/tfCb/cvhzV3Wbo Ttv3WBFahMSg9bN/6ew7CdQpcAhtelcy/LXeMazyeGdxu1aB4BCc4SXbI8w9N/dfexpInVnkB9Z xfEPu+CfZ8gPAsZKC9eudmehQK9DvHZhZTKBM= X-Received: by 2002:a05:600c:a12:b0:482:eec4:758 with SMTP id 5b1f17b1804b1-48526967a7emr143636505e9.26.1772991340683; Sun, 08 Mar 2026 10:35:40 -0700 (PDT) Received: from WindFlash.powerhub ([2a0a:ef40:1b2a:fa01:9944:6a8c:dc37:eba5]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4853a310b8fsm37581865e9.11.2026.03.08.10.35.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 10:35:39 -0700 (PDT) From: Leonardo Bras To: Marcelo Tosatti Cc: Leonardo Bras , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Johannes Weiner , Michal Hocko , 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 Subject: Re: [PATCH 3/4] swap: apply new queue_percpu_work_on() interface Date: Sun, 8 Mar 2026 14:35:30 -0300 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: <20260206143430.021026873@redhat.com> <20260206143741.589656953@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 Content-Transfer-Encoding: 8bit On Thu, Feb 26, 2026 at 12:49:18PM -0300, Marcelo Tosatti wrote: > On Fri, Feb 06, 2026 at 10:06:28PM -0300, Leonardo Bras wrote: > > > + cpu = smp_processor_id(); > > > > Wondering if for these cases it would make sense to have something like: > > > > qpw_get_local_cpu() and > > qpw_put_local_cpu() > > > > so we could encapsulate these migrate_{en,dis}able() > > and the smp_processor_id(). > > > > Or even, > > > > int qpw_local_lock() { > > migrate_disable(); > > cpu = smp_processor_id(); > > qpw_lock(..., cpu); > > > > return cpu; > > } > > > > and > > > > qpw_local_unlock(cpu){ > > qpw_unlock(...,cpu); > > migrate_enable(); > > } > > > > so it's more direct to convert the local-only cases. > > > > What do you think? > > Switched to local_qpw_lock variants. > > > > { > > > - local_lock(&cpu_fbatches.lock); > > > - lru_add_drain_cpu(smp_processor_id()); > > > > and here ? > > Fixed lack of migrate_disable/migrate_enable, thanks! > > > > @@ -950,7 +954,7 @@ void lru_cache_disable(void) > > > #ifdef CONFIG_SMP > > > __lru_add_drain_all(true); > > > #else > > > - lru_add_mm_drain(); > > > > and here, I wonder > > This is !CONFIG_SMP, so smp_processor_id is always 0. > > > > drain_pages(cpu); > > > > > > /* > > > > > > > > > > TBH, I am still trying to understand if we need the migrate_{en,dis}able(): > > - There is a data dependency beween cpu being filled and being used. > > - If we get the cpu, and then migrate to a different cpu, the operation > > will still be executed with the data from that starting cpu > > Yes, but on a remote CPU. What prevents the original CPU from accessing > its per-CPU local data, therefore racing with the code executing on the > remote CPU. Yes, but really rarely, and contention even more rare. It also should not break anything, as locking will make sure access to that per-cpu value is being serialized. I was wondering on the extra cost of migrate_* on the hot path being an undesired effect for other code evaluating switching to QPW. But maybe it's not that bad, and we get rid of that very rare contention. Thanks! Leo > > > - But maybe the compiler tries to optize this because the processor number > > can be on a register and of easy access, which would break this. > > > > Maybe a READ_ONCE() on smp_processor_id() should suffice? > > > > Other than that, all the conversions done look correct. > > > > That being said, I understand very little about mm code, so let's hope we > > get proper feedback from those who do :) > > > > Thanks! > > Leo > > > > >