Re: [Linux-ia64] switch_stack position

Keith Owens
2000-12-14T03:46:20Z

On Wed, 13 Dec 2000 18:56:21 -0800,
David Mosberger <davidm@hpl.hp.com> wrote:
>>>>>> On Wed, 13 Dec 2000 16:03:17 +1100, Keith Owens <kaos@melbourne.sgi.com> said:
> Keith> I am adding support for separate pt_regs and switch_stack by
> Keith> adding struct switch_stack *sw; to struct thread and struct
> Keith> switch_stack *prev_sw; to struct switch_stack.
> Keith> DO_SAVE_SWITCH_STACK and DO_LOAD_SWITCH_STACK track the
> Keith> position of the last switch_stack (LIFO), copy_thread sets
> Keith> prev_sw to NULL for a new process.
>
>Ouch.

No big deal. 5 new instructions (1 extra bundle) in save_switch_stack,
3 new instructions (no extra bundles) in load_switch_stack. One
assignment to 0 in copy_thread(). Plus one __u64 in struct
switch_stack.

> Keith> this removes the need for kdb for ia64 to save switch_stack
> Keith> on every fault. Instead the switch_stack can be delayed
> Keith> until we know that kdb is actually going to do some work. It
> Keith> is a little more work for kdb to unwind from switch_stack
> Keith> back to the point that pt_regs was pushed but it will be much
> Keith> faster than DO_SAVE_SWITCH_STACK on every fault.
>
>That may be a legitimate goal, but surely it doesn't warrant rewriting
>the context switch code. In fact, if you're willing to unwind, all
>the code you need is there already.

The problem is anything that wants to look at other processes on SMP;
kdb and get_wchan are two examples. Currently kdb assumes that any
process which is not current on _this_ cpu is blocked. But the process
could be running on another cpu. kdb needs a safe way of getting the
last switch_stack for any process or of determining that the process
has no switch_stack and therefore cannot be reported.

> Keith> Before I spend too much time on this change, is there any
> Keith> obvious reason why separate pt_regs and switch_stack will not
> Keith> work, as long as I track where switch_stack is?
>
>Like I said above, they already are separate. The only places where
>they are assumed to be consecutive is where (a) the switch stack is
>needed anyhow (clone(), for example) or where unwinding would be too
>costly (unaligned handler).

My earlier mail was a bit strong, I had missed unw_init_running(),
there are no comments on that function to say what it is doing.
Nevertheless I have a need to safely find the switch_stack data on
arbitrary processes. Tracking the position of the latest switch_stack
via a LIFO chain is cheap for the benefits it gives.