Date: Sun, 28 Nov 1999 14:11:13 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: arch@freebsd.org Subject: kernel entry costs. Message-ID: <Pine.BSF.4.10.9911281352050.544-100000@current1.whistle.com>
next in thread | raw e-mail | index | archive | help
Peter wrote: > > Matt wrote: > > :(Julian wrote...) > > : > > :Am I also right in assuming that all the registers that the user was > > :running when they did the KERNCALL have been saved on the KERNEL stack by > > :the time that the above routines are called? > > : > > :(It's a pitty because if they were saved on the USER stack before the > > :kernel switched to the kernel stack it would have a great simplifying > > :effect on kernel threads support :-) (I know that could lead to traps > > :during saving the context but..) > > [..] > > Julian, you shouldn't worry about userland<->kernel context switchso much. > > The overhead for going into the kernel and coming out again, if all the > > cruft is removed, is *very* tiny -- it's almost like a subroutine call. > > I was rather suprised when I found out just how expensive kernel entry was > some time ago.. What I was doing was a reentrant syscall that aquired no > locks and ran about 5 instructions in kernel context.. Anyway, it took > something like 300 times longer to do that (called via int $0x81) than to > do a 'call' to equivalent code in userland. Anyway, with overheads on that > scale, whether we push 5 or 8 or whatever registers in the handler is > almost lost in the noise. > So I don't have my Intel books here, but My take on it is that the following happens: the IDT vercor is read leading to the Interrupt gate that must be read, leading to the loading of the code and stack segment registers, and a new SP and IP (PC), and resetting of processor 'ring' related stuff. The Old SP is saved on the new Stack. (Where does it store the old IP?) it then throws on the interrupt number and such and our routine saves all the registers and the other segment registers. the new segment registers are then loaded. The generic syscall code is called, and the appropriate function is selected and called. (This does not include any Ktrace stuff) on return, the return values are saved into the registers in a towers of hanoi simulation as the registers are reloaded and the segment registers are reloaded. Then the flags , SP and IP are reloaded. this is not an insignificant amount of work! Now that we have the vmware runnng, can we single step FreeBSD kernel through this and see what it actually goes through? that would be a fun thing to do :-) Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9911281352050.544-100000>