Date: Fri, 24 Mar 2000 03:57:40 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: freebsd-current@freebsd.org Subject: Anyone know why the syscall interface is using the doreti mechanism? Message-ID: <200003241157.DAA10683@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
I understand why interrupts use the doreti mechanism. I don't understand why the syscall interface traps have to use it. As far as I can tell, the cpl stuff does not have to be checked at all, the spl does not have to be set to 0 (it damn well better already be 0!), pending interrupts should not have to be checked because interrupts are operating just fine and any code that raises the spl will have dropped it prior to returning, So really only astpending needs to be checked... which can be done inside syscall() rather then doreti. What am I doing? I'm experimenting with trying to remove the MP lock from the syscall path (in exception.s and trap.c). I added a per-syscall flag to tell syscall() whether any given syscall is MP safe or not, and if the syscall IS MP safe then the entire nominal path can be run without obtaining the MP lock. Alfred tried to do this several months ago but the SMP code was still too messy. The SMP code is still messy, but there has been lots of cleanup between then and now. Yes, I have, in fact, successfully taken the MP lock out of the entire syscall path (ok ok, I get the lock for things like ktrace and other non-critical-path items). I'm running a buildworld right now and it hasn't crashed yet! This is surprising because it is almost 4:00 a.m. and the blessed thing actually rebooted normally the first time after I hacked in the changes. On a 2-way SMP P-III 450 a single process timing getuid() calls results in about 1.06 uS (instead of 1.6 uS) per call, and when I have two processes timing they can each do it in 1.3 uS (instead of 4.8 uS with the MP lock). Hoya! Even the syscalls that need the MP lock gain a little. It was all very straightforward except for the doreti stuff that the two syscall gates in i386/i386/excep4tion.s return through. Now, I know I MUST be missing something... but the friggin system is working! No lockups or anything. I'm confident that if I *AM* missing something it will be relatively easy to fix. For the doreti stuff I, well, I ripped it out and replaced it with a few pops and an iret. So question #1: Why is my system still working, what I did has *got* to be illegal! The darned thing is doing a buildworld as I type... still no crash. It isn't getting stuck. Nothing, nada. Normal boring operation. Not even a cool panic! I also have a second question. As far as I can tell, the fuword() and copyin() functions are SMP safe (don't need the MP lock). As far as I can tell if they cause a fault the fault trap will obtain the MP lock as necessary. Anyone know for sure? (Note: I haven't tried taking copyout() or suword() out of the MP lock yet, I'm much less certain about them being MP safe). No patches available yet, I want to refine this a little more before I present it. So far it's quite clean. -Matt Matthew Dillon <dillon@backplane.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003241157.DAA10683>