Re: [PATCH v2] mm: vmscan: fix the page state calculation in too_many_isolated

From: Michal Hocko <mhocko@suse.cz>
To: Christoph Lameter <cl@linux.com>
Cc: Vinayak Menon <vinmenon@codeaurora.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, hannes@cmpxchg.org,
	vdavydov@parallels.com, mgorman@suse.de, minchan@kernel.org
Subject: Re: [PATCH v2] mm: vmscan: fix the page state calculation in too_many_isolated
Date: Mon, 26 Jan 2015 18:46:06 +0100	[thread overview]
Message-ID: <20150126174606.GD22681@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.11.1501221010510.3937@gentwo.org>

On Thu 22-01-15 10:11:31, Christoph Lameter wrote:
> On Wed, 21 Jan 2015, Michal Hocko wrote:
> 
> > I think we can solve this as well. We can stick vmstat_shepherd into a
> > kernel thread with a loop with the configured timeout and then create a
> > mask of CPUs which need the update and run vmstat_update from
> > IPI context (smp_call_function_many).
> 
> Please do not run the vmstat_updates concurrently. They update shared
> cachelines and therefore can cause bouncing cachelines if run concurrently
> on multiple cpus.

Would you preffer to call smp_call_function_single on each CPU
which needs an update? That would make vmstat_shepherd slower but that
is not a big deal, is it?

Anyway I am wondering whether the cache line bouncing between
vmstat_update instances is a big deal in the real life. Updating shared
counters whould bounce with many CPUs but this is an operation which is
not done often. Also all the CPUs would have update the same counters
all the time and I am not sure this happens that often. Do you have a
load where this would be measurable?
-- 
Michal Hocko
SUSE Labs