From: Corey Minyard <cminyard@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>, minyard@acm.org
Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mips: Save all registers when saving the frame
Date: Tue, 23 Sep 2014 11:12:30 -0500 [thread overview]
Message-ID: <54219BEE.7090309@mvista.com> (raw)
In-Reply-To: <541AD6E9.2010609@mvista.com>
Ping? I haven't heard anything on this.
Thanks,
-corey
On 09/18/2014 07:58 AM, Corey Minyard wrote:
> On 09/18/2014 04:58 AM, Ralf Baechle wrote:
>> On Tue, Sep 16, 2014 at 04:45:25PM -0500, minyard@acm.org wrote:
>>
>>> From: Corey Minyard <cminyard@mvista.com>
>>>
>>> The MIPS frame save code was just saving a few registers, enough to
>>> do a backtrace if every function set up a frame. However, this is
>>> not working if you are using DWARF unwinding, because most of the
>>> registers are wrong. This was causing kdump backtraces to be short
>>> or bogus.
>>>
>>> So save all the registers.
>> The stratey of partial and full stack frames was developed in '97 to bring
>> down the syscall overhead. It certaily was very effective - it brought
>> down the syscall latency to the level of Alphas running at much higher
>> clock.
>>
>> That certainly worked well back then for kernel 2.0 / 2.2. But the syscall
>> code has become much more complex. Since then support for 64 bit kernels,
>> two 32 bit ABIs running on a 64 bit kernels and numerous features that
>> changed the once simple syscall path have been implemented. My gut feeling
>> is it might be worth to yank out the whole optimization to see how much
>> code complexity we get rid of in exchange for how much extra syscall
>> latency.
> I"m not sure I understand. From what I can tell, this code is only
> called by
> things that print stack traces, kdb, and kexec/kdump. So it shouldn't be in
> any normal syscall path.
>
> This patch will currently only help kdump, but it will be necessary if
> anyone
> adds MIPS support for DWARF unwinding for stack traces. And you'd have
> to fix some things in context switching, too, I think.
>
> From what I can tell the partial save for syscalls is a good idea. You
> don't have
> to save half the registers and it doesn't affect tracebacks, kdump, or
> anything else
> like that.
>
> -corey
prev parent reply other threads:[~2014-09-23 16:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-16 21:45 [PATCH] mips: Save all registers when saving the frame minyard
2014-09-16 23:24 ` Corey Minyard
2014-09-18 9:58 ` Ralf Baechle
2014-09-18 12:58 ` Corey Minyard
2014-09-23 16:12 ` Corey Minyard [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54219BEE.7090309@mvista.com \
--to=cminyard@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=minyard@acm.org \
--cc=ralf@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox