[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y71XpnJGumySL9ej@lothringen>
Date: Tue, 10 Jan 2023 13:18:46 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: Christoph Lameter <cl@...two.de>
Cc: Marcelo Tosatti <mtosatti@...hat.com>, atomlin@...mlin.com,
tglx@...utronix.de, mingo@...nel.org, peterz@...radead.org,
pauld@...hat.com, neelx@...hat.com, oleksandr@...alenko.name,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v13 2/6] mm/vmstat: Use vmstat_dirty to track
CPU-specific vmstat discrepancies
On Tue, Jan 10, 2023 at 01:06:37PM +0100, Christoph Lameter wrote:
> On Thu, 5 Jan 2023, Marcelo Tosatti wrote:
> > @@ -577,6 +579,9 @@ static inline void mod_zone_state(struct
> > s8 __percpu *p = pcp->vm_stat_diff + item;
> > long o, n, t, z;
> >
> > + /* cmpxchg and vmstat_mark_dirty should happen on the same CPU */
> > + preempt_disable();
>
> If you are disabling preemption then why do we still need cmpxchg?
> Same again below.
Note I'm absolutely clueless with vmstat. But I was wondering about it as well
while reviewing Marcelo's series, so git blame pointed me to:
7c83912062c801738d7d19acaf8f7fec25ea663c ("vmstat: User per cpu atomics to avoid
interrupt disable / enable")
And this seem to mention that this can race with IRQs as well, hence the local
cmpxchg operation.
Powered by blists - more mailing lists