Date: Fri, 29 Oct 1999 10:19:44 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Doug Rabson <dfr@nlsystems.com> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, freebsd-hackers@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: ip forwarding broken on alpha Message-ID: <14361.41684.912860.445771@grasshopper.cs.duke.edu> In-Reply-To: <Pine.BSF.4.10.9910291027070.331-100000@salmon.nlsystems.com> References: <14360.62787.116526.830259@grasshopper.cs.duke.edu> <Pine.BSF.4.10.9910291027070.331-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14361.41684.912860.445771>