Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!foxhound.dsto.gov.au!fang.dsto.gov.au!myall.awadi.com.au!myall!blymn From: blymn@awadi.com.au (Brett Lymn) Newsgroups: comp.os.386bsd.development Subject: Re: V86 mode & the BIOS (was Need advice: Which OS to port to?) Date: 23 Aug 93 13:16:08 Organization: AWA Defence Industries Lines: 62 Message-ID: <BLYMN.93Aug23131608@mallee.awadi.com.au> References: <3390@vall.dsv.su.se> <108457@hydra.gatech.EDU> <1993Aug12.110032.16307@cnplss5.cnps.philips.nl> <BLYMN.93Aug15160011@siren.awadi.com.au> <24nstc$554@klaava.Helsinki.FI> NNTP-Posting-Host: mallee.awadi.com.au In-reply-to: torvalds@klaava.Helsinki.FI's message of 16 Aug 1993 15:00:43 +0300 >>>>> On 16 Aug 1993 15:00:43 +0300, torvalds@klaava.Helsinki.FI (Linus Torvalds) said: Linus> 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: > >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). Linus> The TSS IO bitmap pointer is sadly only 16 bits, and has to point to Linus> within the TSS segment anyway, so juggling with the IO bitmap is Linus> essentially not an option, and you do indeed need to copy the bitmap at Linus> task switch or use separate TSS's (of course, you can try to optimize Linus> away some of the copying as most processes don't use the IO bitmap at Linus> all, but the logic behind that is probably slower than the copying). Yes, the TSS I/O bitmap pointer is sadly crippled *but* in the case of 386BSD it is not as bad as it sounds. There is only one TSS in the system, task switching is not performed by doing a jump TSS it is done "manually", though the *BSD PCB does contain all the fields for the TSS they are not all used. Having a I/O bitmap would not slow the task switch down much, just an extra register load should do it. Most of the slow work would be done in the I/O bitmap change request routine. This routine could modify the PCB and copy the bitmap, the logic would only have to be done once per i/o bitmap modification so would not impact performance too much. Linus> The i386/i486 documentation all seem to suggest doing task switches by Linus> hand if you want optimal performance due to the slowness of the Linus> task-switch, but I have my doubts about the validity of that.. It's Linus> probably faster to switch in software if you need to save only limited Linus> state, but when you need to set the TS bit (for the math coprocessor), Linus> change cr3 (the page directory pointer), and update the TSS, doing it in Linus> software is probably not any faster than the simpler longjump to a TSS Linus> segment. I too have my doubts about the speed, that is why I said *may* but I would have to add up all the numbers for the task switch, the jump TSS is easy - it is about 240 Clock cycles but determining the speed of the current system requires a bit of skull/databook work that I have not done. Linus> I actually did some timing tests on this: the linux kernel has Linus> traditionally used the TSS jump for task switching due to simplicity, Linus> but I rewrote the fork/exec to allow software task switching without Linus> problems. Performance went down wen doing it in software, even though I Linus> got rid of some register loads that way. Note that I didn't try to Linus> over-optimize it, so it's still possible that the software taskswitch Linus> approach may be faster, but it does indicate that there at least is no Linus> major need to try to avoid the i386 hardware task-switching features. I Linus> can only suggest that 386bsd kernel hackers should try it out. *BSD saves a very minimal state. As you say probably the easiest way would be to suck it and see. Most of the work was done by Bill Jolitz so the impact is not that great. -- Brett Lymn