Doug Rabson writes:
>
> I think the intention of ASTs is that they are generated whenever you are
> returning to user mode. This patch will essentially defer the AST until
> the next system call which might be unacceptable.
Whoops! I hadn't realized this.
> I can see the window and its a serious problem but I'm worried about
> fixing it in this way. What I really want is some way to generate a 'real'
> AST after the PALcode has dropped the exception frame for the interrupt.
> Without changing to use the VMS palcode, we aren't going to get that
> though :-). (ASTs and SWIs are derived from the way VAXen work and the VMS
> palcode emulates the old vax behaviour).
>
> The main problem as I see it is that we are dropping the IPL to zero
> before calling the ast. I don't see why we are doing this at all. We
> should be able to just call the ast without changing the ipl at all. This
> still leaves a window in do_sir (which lowers the IPL to 1) though.
I think this is safe because if we don't lower the ipl to 0, then we
cannot get recursion because of this check:
ldq s1, (FRAME_PS * 8)(sp) /* get the saved PS */
and s1, ALPHA_PSL_IPL_MASK, t0 /* look at the saved IPL */
bne t0, Lrestoreregs /* != 0: can't do AST or SIR */
I think the worst that can happen is
0: ?: ipl0, interrupted
1: device interrupt : ipl4 prev. ipl == 0 --> calls do_sir, lowers ipl to 1,
interrupted
2: device interrupt : ipl4, previous ipl != 0, returns
> Perhaps, SWIs should be handled by using another kernel thread which can
> be switched to instead of calling do_sir. I have to think about that some
> more. Could you test just removing the swpipl(0) code and see if it
> improves things, thanks.
Yes, it improves things. Removing the swpipl(0) appears to make an
alpha stable under extreme interrupt load. I'm most of the way
through a cvs checkout of -current while forwarding about 15,000
packets/sec. If I can get through a buildworld under this load, I'll
call it stable.
I am also curious as to why the swpipl(0) was there in the first
place. I was initially concerned that it was required for some reason
I did not understand (like something higher up was expecting
exception_return to clean up the ipl state). I did know that the
PALcode puts the ipl back where it was after a hardware interrupt.
This is another reason I previously thought that special casing
hardware interrupts might be the right thing to do.
I looked at NetBSD's CVS web, and it looks like it has been there
since day one. It will be nice to loose it, as it should reduce
overhead quite a bit.
For clarity, I'm running with just the following now:
Index: swtch.s
===================================================================
RCS file: /home/ncvs/src/sys/alpha/alpha/swtch.s,v
retrieving revision 1.11
diff -u -c -r1.11 swtch.s
cvs diff: conflicting specifications of output style
*** swtch.s 1999/08/28 00:38:32 1.11
--- swtch.s 1999/10/29 13:39:46
***************
*** 263,271 ****
CALL(do_sir) /* do the SIR; lowers IPL */
Lchkast:
- ldiq a0, ALPHA_PSL_IPL_0 /* drop IPL to zero*/
- call_pal PAL_OSF1_swpipl
-
and s1, ALPHA_PSL_USERMODE, t0 /* are we returning to user? */
beq t0, Lrestoreregs /* no: just return */
--- 263,268 ----
Thanks,
Drew
------------------------------------------------------------------------------
Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science Phone: (919) 660-6590
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
