Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!mcsun!news.funet.fi!klaava!klaava!not-for-mail From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.386bsd.development Subject: Re: V86 mode & the BIOS (was Need advice: Which OS to port to?) Date: 16 Aug 1993 15:00:43 +0300 Organization: University of Helsinki Lines: 56 Message-ID: <24nstc$554@klaava.Helsinki.FI> References: <3390@vall.dsv.su.se> <108457@hydra.gatech.EDU> <1993Aug12.110032.16307@cnplss5.cnps.philips.nl> <BLYMN.93Aug15160011@siren.awadi.com.au> NNTP-Posting-Host: klaava.helsinki.fi In article <BLYMN.93Aug15160011@siren.awadi.com.au> blymn@awadi.com.au (Brett Lymn) writes: >>>>>> On Thu, 12 Aug 1993 11:00:32 GMT, rooij@bashful.isp.cft.philips.nl (Guido van Rooij) said: > >Guido> gt8134b@prism.gatech.EDU (Howlin' Bob) writes: > >>As for slow task switching, the 386 doesn't access the I/O permissions >>bitmap until an I/O instruction occurs. The size of the bitmap has >>no effect on task switching performance. > >Guido> The reason this was brought up is the fact that on task switching you >Guido> also need somehow to get the io permission bitmap in the TSS. Since >Guido> 386bsd does not use the builtin taskswitching of the 386, theis bitmap >Guido> has to be memcpy'd into the TSS, resullting in slow task switches. > >I do not think that we need to copy the i/o bitmap at all. There are >a couple of alternatives. One is modify the TSS location on a task >switch to point at a different i/o bitmap. Each task need not have >it's own i/o bitmap, they can use the default one until they request a >change - then the bitmap could be copied and updated as requested >(sort of a copy on write scheme). The TSS IO bitmap pointer is sadly only 16 bits, and has to point to within the TSS segment anyway, so juggling with the IO bitmap is essentially not an option, and you do indeed need to copy the bitmap at task switch or use separate TSS's (of course, you can try to optimize away some of the copying as most processes don't use the IO bitmap at all, but the logic behind that is probably slower than the copying). >The other alternative is to actually use a TSS for each process and do >a jump through the TSS. According to Bill Jolitz the only reason for >the scheme we have at the moment is it only saves 8 registers instead >of 20, the scheme is supposed to be faster than doing a jmp through a >TSS. In fact if you look at the pcb structure it already has all the >TSS structure there so making use of it would not change any kernel >data structures. The i386/i486 documentation all seem to suggest doing task switches by hand if you want optimal performance due to the slowness of the task-switch, but I have my doubts about the validity of that.. It's probably faster to switch in software if you need to save only limited state, but when you need to set the TS bit (for the math coprocessor), change cr3 (the page directory pointer), and update the TSS, doing it in software is probably not any faster than the simpler longjump to a TSS segment. I actually did some timing tests on this: the linux kernel has traditionally used the TSS jump for task switching due to simplicity, but I rewrote the fork/exec to allow software task switching without problems. Performance went down wen doing it in software, even though I got rid of some register loads that way. Note that I didn't try to over-optimize it, so it's still possible that the software taskswitch approach may be faster, but it does indicate that there at least is no major need to try to avoid the i386 hardware task-switching features. I can only suggest that 386bsd kernel hackers should try it out. Linus