[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1605240101030.31937@cbobk.fhfr.pm>
Date: Tue, 24 May 2016 01:02:43 +0200 (CEST)
From: Jiri Kosina <jikos@...nel.org>
To: Andy Lutomirski <luto@...capital.net>
cc: Josh Poimboeuf <jpoimboe@...hat.com>,
Ingo Molnar <mingo@...hat.com>, X86 ML <x86@...nel.org>,
Heiko Carstens <heiko.carstens@...ibm.com>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
live-patching@...r.kernel.org,
Michael Ellerman <mpe@...erman.id.au>,
Chris J Arges <chris.j.arges@...onical.com>,
linuxppc-dev@...ts.ozlabs.org, Jessica Yu <jeyu@...hat.com>,
Petr Mladek <pmladek@...e.com>, Jiri Slaby <jslaby@...e.cz>,
Vojtech Pavlik <vojtech@...e.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Miroslav Benes <mbenes@...e.cz>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ
tracking
On Fri, 20 May 2016, Andy Lutomirski wrote:
> I think it would be negligible, at least for interrupts, since
> interrupts are already extremely expensive. But I don't love adding
> assembly code that makes them even slower. The real thing I dislike
> about this approach is that it's not a normal stack frame, so you need
> code in the unwinder to unwind through it correctly, which makes me
> think that you're not saving much complexity by adding the pushes.
I fail to see what is so special about the stack frame; it's in fact
pretty normal.
It has added semantic value for "those who know", but the others will
(pretty much correctly) consider it to be a stackframe from a function
call, and be done with it.
What am I missing?
Thanks,
--
Jiri Kosina
SUSE Labs
Powered by blists - more mailing lists