From: Keith Owens <kaos@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [patch] Resched skip_rbs_switch to run 4 cycles faster on McKinley-type cores.
Date: Wed, 19 Jan 2005 22:25:35 +0000 [thread overview]
Message-ID: <17598.1106173535@kao2.melbourne.sgi.com> (raw)
In-Reply-To: <200501190500.j0J505jY002441@napali.hpl.hp.com>
Damn, I was in the middle of developing a patch against this area :(.
David, since you are redoing some of this code, I probably need to
discuss my changes. My aim is to allow the kernel unwinder to work on
the per-cpu MCA and INIT stacks that Russ Anderson (rja) recently
added. This has never been an issue before because we only had one
stack and could not handle INIT over MCA.
The problem with unwinding from the MCA or INIT stacks is handling the
change of rbs. The current code assumes that all kernel work is done
on the same rbs, which is not true for the MCA and INIT stacks. I plan
to change the meaning of pt_regs ar_bspstore and ar_rnat. Instead of
being garbage when the interrupted code was in the kernel, ar_bspstore
and ar_rnat are set to zero. The test for "do I skip_rbs_switch"
changes from pUStk to "is saved ar_bspstore non-zero".
Interrupts in kernel context save a zero ar_bspstore and skip the rbs
swicth on return from interrupt. Interrupts in user context save a
valid ar_bspstore and switch rbs on exit. MCA and INIT events will
synthesize and save struct pt_regs on the MCA/INIT stack, this pt_regs
will contain non-zero ar_bspstore pointing back to the previous bsp,
which could be in a kernel or user space stack.
Comments?
next prev parent reply other threads:[~2005-01-19 22:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-19 5:00 [patch] Resched skip_rbs_switch to run 4 cycles faster on McKinley-type cores David Mosberger
2005-01-19 22:25 ` Keith Owens [this message]
2005-01-20 6:50 ` David Mosberger
2005-01-20 10:26 ` Keith Owens
2005-01-20 17:01 ` David Mosberger
2005-01-28 2:08 ` David Mosberger
2005-01-28 3:04 ` Keith Owens
2005-01-28 5:22 ` David Mosberger
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=17598.1106173535@kao2.melbourne.sgi.com \
--to=kaos@sgi.com \
--cc=linux-ia64@vger.kernel.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