Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes

From: Tejun Heo <tj@kernel.org>
To: Colin Cross <ccross@google.com>
Cc: John Stultz <john.stultz@linaro.org>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Dmitry Shmidt <dimitrysh@google.com>,
	Rom Lemarchand <romlem@google.com>, Todd Kjos <tkjos@google.com>,
	Oleg Nesterov <oleg@redhat.com>
Subject: Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes
Date: Wed, 13 Jul 2016 16:54:33 -0400	[thread overview]
Message-ID: <20160713205433.GD29670@mtj.duckdns.org> (raw)
In-Reply-To: <CAMbhsRSi4ZxBVokhZJfPotJhTjDD_SFK8BYPr7sb5J-4UE400g@mail.gmail.com>

Hello,

On Wed, Jul 13, 2016 at 01:44:50PM -0700, Colin Cross wrote:
> > Switching between foreground and background isn't a hot path.  It's
> > human initiated operations after all.  It taking 80 msecs sure is
> > problematic but I'm skeptical that this is from actual contention
> > given that the only reader side holders are fork and exit paths.
> 
> Slight correction here, we move tasks to the foreground cgroup and
> back around binder IPC calls from foreground processes to background
> processes, so it is significantly hotter than just human initiated
> operations.

Oh I see.  That's extreme and you would be paying in terms of
migration overhead.  It really doesn't make sense to generally
optimize for migration as that often translates directly to overhead
in actual hot paths in various controllers.  That said, I don't think
it'd be too difficult to keep things acceptable for the android case.

Thanks.

-- 
tejun