MIME-Version: 1.0
In-Reply-To: <551C6A48.9060805@canonical.com>
References: <CAMiJ5CU+rvQr-_Ejd3m3ha3HsiSKu0Sq_fTaE2Ws_c_01=qbLQ@mail.gmail.com>
	<CA+55aFxWBKHth7x3FJ+dpGfy0ZT7SUhHnX7tDfgDo-wXTeX5Lg@mail.gmail.com>
	<CA+55aFx2n9zsqwuW=p6KJF62rXp+9_M-HF3wbeJRA-MeT0XLLw@mail.gmail.com>
	<CA+55aFyv1pJod7bhetc0ikmuCKzE=uhmT14KMju_fTbP93gLWA@mail.gmail.com>
	<CA+55aFxd1WGNBzSHeOGiXXdUD1GqDYv9PUNGdrdiGFwaX7HYJQ@mail.gmail.com>
	<CA+55aFxFkw7cKu6R8-v9z=c+yG+jsPHyQKW5-yyn3+M0BuyvxA@mail.gmail.com>
	<20150331031536.GA9303@canonical.com>
	<CA+55aFykg3SAO16=NRiC+tP1gGj5hgbu+Y93ss4Qg30+qyZ=+w@mail.gmail.com>
	<20150331222327.GA12512@canonical.com>
	<20150401124336.GB12841@gmail.com>
	<20150401161047.GD12730@canonical.com>
	<CA+55aFxQ6q7MNS+4XWZ3=Xa0Hz6kumd84v_aEw3M4gBpXszTkQ@mail.gmail.com>
	<551C6A48.9060805@canonical.com>
Date: Thu, 2 Apr 2015 10:31:50 -0700
Message-ID: <CA+55aFw2Jb4ASOxckY1cwP23fAYv5dG1WYCkB6RyjjpP2hEQcw@mail.gmail.com>
Subject: 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>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1259
Lines: 26

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/