*BSD News Article 19582


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