Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!spool.mu.edu!usenet.eel.ufl.edu!bofh.dot!hookup!usc!newshub.csu.net!imci3!newsfeed.internetmci.com!news.sprintlink.net!new-news.sprintlink.net!helena.MT.net!nate
From: nate@trout.sri.MT.net (Nate Williams)
Newsgroups: comp.unix.bsd.misc
Subject: Re: kernel/context switch
Date: 22 May 1996 16:27:17 GMT
Organization: SRI Intl. - Montana Operations
Lines: 36
Message-ID: <4nvf95$4as@helena.MT.net>
References: <4ntet4$7mv@ennui.eng.octel.com>
Reply-To: "Nate Williams" <nate@sneezy.sri.com>
NNTP-Posting-Host: trout.sri.mt.net
In article <4ntet4$7mv@ennui.eng.octel.com>, John Pham <johnp@octel.com> wrote:
>I notice in the kernel that the context switch time is every 100 msec
>or 10 times a second. Is there any reason why it is set to every 100msec and
>not 50msec or 25msec?
Becuase it's a trade-off between spending more time in the applications
vs. spending allyour time 'switching' between applications.
The time spent scheduling & saving/restoring the context of the
processes becomes significant the smaller you make your quantum.
Let's say it takes 2ms. So, with a 100ms quatnum, you lose about 2% of
the CPU time for straight overhead of the context switch time. If we
make the quantum 50ms, now 4% of CPU is spent switching, and vice-versa.
In a more real-world example, it's like having the phone ring, and each
time the phone rings you have to do something new. So, the less *often*
the phone rings the more work you get done on any one project, and the
more often the phone rings the more often each project gets something
doen. However, as we all know the time it takes to save the paperwork
from one project and dig up the new paperwork is non-trivial, thus if
the phone rings really often we spend all our time saving playing wiht
paperwork and not spending anytime getting 'work' done. In the same
manner the scheduler makes an attempt to balance out keeping things
'fair' while still giving each process a significant 'slice' of time.
Hope this helps,
Nate
--
nate@sri.com | Research Engineer, SRI Intl. - Montana Operations
nate@trout.mt.sri.com | Loving life in God's country, the great state of
work #: (406) 449-7662 | Montana.
home #: (406) 443-7063 | A fly pole and a 4x4 Chevy truck = Heaven on Earth