Re: smp_call_function_single lockups

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Chris J Arges <chris.j.arges@canonical.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	Rafael David Tinoco <inaddy@ubuntu.com>,
	Peter Anvin <hpa@zytor.com>,
	Jiang Liu <jiang.liu@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>, Jens Axboe <axboe@kernel.dk>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Gema Gomez <gema.gomez-solano@canonical.com>,
	"the arch/x86 maintainers" <x86@kernel.org>
Subject: Re: smp_call_function_single lockups
Date: Thu, 2 Apr 2015 10:31:50 -0700	[thread overview]
Message-ID: <CA+55aFw2Jb4ASOxckY1cwP23fAYv5dG1WYCkB6RyjjpP2hEQcw@mail.gmail.com> (raw)
In-Reply-To: <551C6A48.9060805@canonical.com>

On Wed, Apr 1, 2015 at 2:59 PM, Chris J Arges
<chris.j.arges@canonical.com> wrote:
>
> It is worthwhile to do a 'bisect' to see where on average it takes
> longer to reproduce? Perhaps it will point to a relevant change, or it
> may be completely useless.

It's likely to be an exercise in futility. "git bisect" is realyl bad
at "gray area" things, and when it's a question of "it takes hours or
days to reproduce", it's almost certainly not worth it. Not unless
there is some really clear cut-off that we can believably say "this
causes it to get much slower". And in this case, I don't think it's
that clear-cut. Judging by DaveJ's attempts at bisecting things, the
timing just changes. And the differences might be due to entirely
unrelated changes like cacheline alignment etc.

So unless we find a real clear signature of the bug (I was hoping that
the ISR bit would be that sign), I don't think trying to bisect it
based on how quickly you can reproduce things is worthwhile.

                        Linus