kdq@demott.com (Kevin D. Quitt) (01/23/91)
I am running a cpu-bound, small program (15 pages of memory), on our SYSV system. The startup is automated at boot time, and the program is niced. Is it reasonable to expect that I should see little or no system response-time degradation, or is the UNIX scheduler really that hosed? -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last
rdavis@connie.UUCP (Ray Davis) (01/29/91)
In <1991Jan22.184055.3641@demott.com> kdq@demott.com (Kevin D. Quitt) writes: > I am running a cpu-bound, small program (15 pages of memory), on our >SYSV system. The startup is automated at boot time, and the program is >niced. Is it reasonable to expect that I should see little or no system >response-time degradation, or is the UNIX scheduler really that hosed? It completely depends on your machine, how it is set up and the load. For instance, is your machine a PC/AT with one less than a mip cpu and 1 meg of memory, or a Convex C240 with four ~50 mip cpus and 1 Gigabyte or memory? Also, what is this processed niced to? If it is niced negative then it will have a higher priority. If it is cpu bound, then it will always use it's whole time-slice, which most processes under unix don't do. This might at times degrade response-time, because if the proc gets the cpu, then it won't give it up as soon as other procs might. --Ray
richard@locus.com (Richard M. Mathews) (01/29/91)
rdavis@connie.UUCP (Ray Davis) writes: >If it is cpu bound, then it will always use it's whole time-slice, >which most processes under unix don't do. This might at times >degrade response-time, because if the proc gets the cpu, then it >won't give it up as soon as other procs might. Not necessarily. In many (most?) versions of Unix if an interrupt makes a process runnable at a higher priority than the running process, a context switch will be forced immediately. Since processes waiting for something like tty input will on most systems wake up at a priority higher than that of any user-mode process, perceived response time should not be greatly affected. Or so goes the theory;-) Richard M. Mathews D efend richard@locus.com E stonian-Latvian-Lithuanian lcc!richard@seas.ucla.edu I ndependence ...!{uunet|ucla-se|turnkey}!lcc!richard
boyd@necisa.ho.necisa.oz.au (Boyd Roberts) (01/31/91)
In article <richard.665126102@fafnir.la.locus.com> richard@locus.com (Richard M. Mathews) writes: >... In many (most?) versions of Unix if an interrupt >makes a process runnable at a higher priority than the running process, >a context switch will be forced immediately. No, UNIX does not have pre-emptive scheduling. When the above event occurs the kernel context switches at the next user-mode trap, system call, sleep() or the once-a-second context switch (time quantum expiry). The low level scheduling is done by code executed by the running process which checks whether a context switch is required. If it is, the process gives up the CPU. A higher priority process being made runnable doesn't _force_ the current process to give up the CPU, it gives it up when it notices that it has to. Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
jackv@turnkey.tcc.com (Jack F. Vogel) (02/01/91)
In article <2004@necisa.ho.necisa.oz.au> boyd@necisa.ho.necisa.oz.au (Boyd Roberts) writes: >In article <richard.665126102@fafnir.la.locus.com> richard@locus.com (Richard M. Mathews) writes: >>... In many (most?) versions of Unix if an interrupt >>makes a process runnable at a higher priority than the running process, >>a context switch will be forced immediately. >No, UNIX does not have pre-emptive scheduling. When the above event occurs >the kernel context switches at the next user-mode trap, system call, sleep() >or the once-a-second context switch (time quantum expiry). I think you are nit-picking at Richard's choice of words here. When he said "immediately" it was in a loose sort of sense, not suggesting some sort of preemption at that instruction. But it is also not correct that a context switch will take as long as you suggest. What will happen is that the interrupt will cause the kernel to run in trap(), there it will do whatever serving needs to be done, lets say an event occured that another process was sleeping on, this will cause that process to be put back in the run queues, and runrun will be set true, then at the exit of trap there is a test of runrun and as it will be true a context switch will take place right then. No need for another system call, sleep(), or whatever. >.... A higher priority process being made runnable doesn't >_force_ the current process to give up the CPU, it gives it up when it >notices that it has to. Now you talk as though there is no such thing as "preemption" at all, the running process is "forced" to give up the CPU whenever an involuntary context switch takes place. Perhaps its just a semantic preference to say "it notices that it has to" :-}. Disclaimer: I don't speak for LCC. -- Jack F. Vogel jackv@locus.com AIX370 Technical Support - or - Locus Computing Corp. jackv@turnkey.TCC.COM
richard@locus.com (Richard M. Mathews) (02/01/91)
jackv@turnkey.tcc.com (Jack F. Vogel) writes: >boyd@necisa.ho.necisa.oz.au (Boyd Roberts) writes: >>richard@locus.com (Richard M. Mathews) writes: >>>... In many (most?) versions of Unix if an interrupt >>>makes a process runnable at a higher priority than the running process, >>>a context switch will be forced immediately. > >>No, UNIX does not have pre-emptive scheduling. When the above event occurs >>the kernel context switches at the next user-mode trap, system call, sleep() >>or the once-a-second context switch (time quantum expiry). > >What will happen is that the >interrupt will cause the kernel to run in trap(), there it will do whatever >serving needs to be done Thanks for the defense, Jack. To be explicit, look for the call to aston() in wakeup() in a VAX kernel. This will cause a trap to occur before ANY user mode instructions are executed; that is what I meant by "immediately". Before that trap returns to user mode, it will notice runrun is set and reschedule. In other systems (such as a few different 80*86 kernels I've seen) both traps and interrupts check runrun before returning to user mode and can switch context immediately. Richard M. Mathews Freedom for Lithuania richard@locus.com Laisve! lcc!richard@seas.ucla.edu ...!{uunet|ucla-se|turnkey}!lcc!richard
thomson@hub.toronto.edu (Brian Thomson) (02/01/91)
In article <richard.665353961@fafnir.la.locus.com> richard@locus.com (Richard M. Mathews) writes: >jackv@turnkey.tcc.com (Jack F. Vogel) writes: >>boyd@necisa.ho.necisa.oz.au (Boyd Roberts) writes: >>>richard@locus.com (Richard M. Mathews) writes: >>>>... In many (most?) versions of Unix if an interrupt >>>>makes a process runnable at a higher priority than the running process, >>>>a context switch will be forced immediately. >> >>>No, UNIX does not have pre-emptive scheduling. When the above event occurs >>>the kernel context switches at the next user-mode trap, system call, sleep() >>>or the once-a-second context switch (time quantum expiry). >> >>What will happen is that the >>interrupt will cause the kernel to run in trap(), there it will do whatever >>serving needs to be done > >Thanks for the defense, Jack. To be explicit, look for the call to >aston() in wakeup() in a VAX kernel. This will cause a trap to occur >before ANY user mode instructions are executed; that is what I meant by >"immediately". Before that trap returns to user mode, it will notice >runrun is set and reschedule. In other systems (such as a few different >80*86 kernels I've seen) both traps and interrupts check runrun before >returning to user mode and can switch context immediately. > It is also checked in a few pdp11 kernels I've seen ... UNIX (tm) has traditionally been a single processor operating system of the "monolithic monitor" type. That is to say, once a process begins running in the kernel it is guaranteed that no process switch will occur until it voluntarily relinquishes the processor by calling "swtch()", or exits the kernel by returning to user mode. So, all process switches, including those caused by interrupts, are deferred until one of those things happens. Part of this involves checking the reschedule flag when returning to user mode from a trap or interrupt. The only new wrinkle in the VAX was that the hardware would do this check for you. This being the case, I would have to agree with Mr. Roberts that Mr. Mathews' definition of "forced immediately" is somewhat unconventional ... but to disagree with his assertion that the switch is delayed until the *next* {trap, syscall, etc.}. -- Brian Thomson, CSRI Univ. of Toronto utcsri!uthub!thomson, thomson@hub.toronto.edu
src@scuzzy.in-berlin.de (Heiko Blume) (02/02/91)
richard@locus.com (Richard M. Mathews) writes: >Thanks for the defense, Jack. To be explicit, look for the call to >aston() in wakeup() in a VAX kernel. This will cause a trap to occur >before ANY user mode instructions are executed; that is what I meant by >"immediately". Before that trap returns to user mode, it will notice >runrun is set and reschedule. since not many people can 'look for the call in a VAX kernel', except with adb... "An AST [asynchronous system trap posted by aston()] is a trap that is delivered to a process the next time that process returns to *user* mode. [...] The system [then] interrogates the runrun flag and *forces* a context switch [...]" [p.90 in the 4.3BSD book]. that is, the process will go to user mode, it won't execute any of it's instructions, it will trap into the kernel and will then be PREEMPTED. (only user mode stuff can be preempted, processes in system calls can not.) >In other systems (such as a few different >80*86 kernels I've seen) both traps and interrupts check runrun before >returning to user mode and can switch context immediately. that's because they permit context switching from the interrupt stack (etc), which the VAX architecture does not permit. but the VAX does ASTs in hardware :-) -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
terryl@sail.LABS.TEK.COM (02/06/91)
In article <2007@necisa.ho.necisa.oz.au> boyd@necisa.ho.necisa.oz.au (Boyd Roberts) writes: +In article <1991Jan31.180957.9167@turnkey.tcc.com> jackv@turnkey.TCC.COM (System Administrator) writes: +>... But it is also not correct that a context +>switch will take as long as you suggest. What will happen is that the +>interrupt will cause the kernel to run in trap(), + +Device interrupts do not go through trap(). The stack is munged, the +interrupt routine is called, the stack un-munged and the interrupt is +returned from. No calls to trap(). trap() handles exceptions, not +device interrupts. `Tis true (that device interrupts do not go through trap()), but in almost all modern Unices I've seen, there is a check just right before returning from the interrupt(and it goes like this, in my best Ray Davies imitation!!! (-:): If we were interrupted in USER mode AND We need to reschedule the cpu then call trap() to reschedule the cpu.... __________________________________________________________ Terry Laskodi "There's a permanent crease of in your right and wrong." Tektronix Sly and the Family Stone, "Stand!" __________________________________________________________