[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44f2df1a-ace4-0c44-166f-4f2fef49e0c1@suse.cz>
Date: Wed, 26 Apr 2023 17:04:49 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Marcelo Tosatti <mtosatti@...hat.com>,
Michal Hocko <mhocko@...e.com>
Cc: Frederic Weisbecker <frederic@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Christoph Lameter <cl@...ux.com>,
Aaron Tomlin <atomlin@...mlin.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Russell King <linux@...linux.org.uk>,
Huacai Chen <chenhuacai@...nel.org>,
Heiko Carstens <hca@...ux.ibm.com>, x86@...nel.org
Subject: Re: [PATCH v7 00/13] fold per-CPU vmstats remotely
On 4/20/23 15:45, Marcelo Tosatti wrote:
> Perhaps the complexity should be judged for individual cases
> of interruptions, and if a given interruption-free conversion
> is seen as too complex, then a "disable feature which makes use of per-CPU
> caches" style solution can be made (and then userspace has to
> explicitly request for that per-CPU feature to be disabled).
>
> But i don't see that this patchset introduces unmanageable complexity,
> neither:
>
> 01b44456a7aa7c3b24fa9db7d1714b208b8ef3d8 mm/page_alloc: replace local_lock with normal spinlock
> 4b23a68f953628eb4e4b7fe1294ebf93d4b8ceee mm/page_alloc: protect PCP lists with a spinlock
Well that one is a bit different, as there was one kind of lock replaced
with other kind of lock, the lock is uncontended unless there's remote
flushes happening so it's not causing extra overhead for the fast paths,
and later even the irq disabling was removed, which should even improve
things. But this patchset is turning all vmstat counter increments a
cmpxchg.
Powered by blists - more mailing lists