[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0609271329080.3952@g5.osdl.org>
Date: Wed, 27 Sep 2006 13:35:47 -0700 (PDT)
From: Linus Torvalds <torvalds@...l.org>
To: Andi Kleen <ak@...e.de>
cc: Kyle McMartin <kyle@...isc-linux.org>,
linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
akpm@...l.org
Subject: Re: [BUG] Oops on boot (probably ACPI related)
On Wed, 27 Sep 2006, Linus Torvalds wrote:
>
> On Wed, 27 Sep 2006, Andi Kleen wrote:
> >
> > I expect this patch to fix it.
>
> Andrew, Kyle, can you verify?
Not that it really matters. Andi sure as hell pinpointed a real problem
with the new and broken inline asm. That's almost certainly the bug that
crept in during the recent rewrite.
HOWEVER, now that I look more closely at the rewrite, I'm really wondering
whether the rewrite was worth it at all. It generates smaller code, but at
the expense of
- the actual cache-footprint is bigger
- the branch will now be mis-predicted by default
Since the "smaller code" really only tends to matter from a cache
usage standpoint, I don't know if I'm at all convinced.
The fact that rewinders have problems is fairly immaterial. Maybe we
should just take this as a hint that all the stupid rewinding code was
wrong in the first place, and we should stop doing that? We can go back
to just printing out our stacktrace guesses, that has worked for us for a
long time, and the stack unwinding simply looks _fundamentally_ flawed.
So I have a real urge to just revert that change anyway.
Are there any _real_ advantages to this broken unwinding code that has had
more bugs that Windows XP?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists