`On Fri, 25 Aug 2000, Stuart MacDonald wrote:> From: "Richard B. Johnson" <root@chaos.analogic.com>> > On Fri, 25 Aug 2000, Stuart MacDonald wrote:> >> > > From: "Chris Swiedler" <ceswiedler@mindspring.com>> > > > > Let's say the minimum time is 50 cycles:> > > > >> > > > > Process A last_cpu = 1> > > > > Process B last_cpu = 1> > > > > Process C last_cpu = 1> > > > >> > > > > Process C runs for 200 cycles on CPU 1> > > > > Process C last_cpu = 1> > > > > Process A runs for 300 cycles on CPU 2> > > > > Process A last_cpu = 2> > > > >> > > > > Process C is running on CPU 1> > > > > Process C last_cpu = 1> > > > > Process B runs for 15 cycles on CPU 2 but is interrupted> > > > > Process B last_cpu = 1 (unaltered)> > > > >> > > > > Here we have:> > > > > Process A last_cpu = 2> > > > > Process B last_cpu = 1> > > > > Process C last_cpu = 1> > > > > C is currenty running on 1> > > > > Scheduler needs to pick a process for 2> > > > > A runs on 2> > > > >> > > > > C is starved> > > >> > > > ??? I don't see how C is starved. C and B have an equal chance of> being> > > > scheduled for CPU 1 (barring other factors). Certainly, C won't be> starved> > > > in an extreme sense, because we're only adjusting the goodness(), and> so> > > > eventually it will be scheduled again.> > >> > > Sorry, typo. B is starved. C is already running on 1> > > and has 185 cycles left.> > >> > > Also, I meant starved in that even though B is the> > > process time-affinity scheduling should choose, it> > > won't get chosen.> > >> > > ..Stu> > >> >> > But this is a 'Unix' system, not VMS!  A task that gets interrupted> > will get the CPU back as soon as the ISR is complete. Since you can't> > schedule in an interrupt, this rule is absolute. That is true even> > if a "bottom-half" is queued within the ISR. The bottom-half runs> > after somebody has either given up the CPU, or has it stolen from> > them via a context-switch.> >> > Are you saying that a task will "switch CPUs" as a result of an> > interrupt? I don't think that this is allowed to happen because> > some task that's interrupted isn't going to get interrupted while> > it's interrupted! Some other task might, but not this one.> > Now I know I'm missing something. According to the above two> paragraphs, "time-affinity" scheduling is already the implicit> behaviour.> I think, as you have already observed, is the implicit behavior.> But Chris Swiedler was arguing for it.> > I was just trying to introduce a counter-example to Chris' proposed> changes.> > Did I misunderstand Chris' original proposal?> I don't know. I think there may be some confusion about how Linux/Unixoperates.In VAX/VMS, you have the problem Chris cited because every interruptcauses a context-switch. The task that was interrupted is simply putinto the queue of runnable tasks. Also, any time some task makes asystem-call, it also loses out because it is also put into the queueand won't get the CPU again until the kernel has completed whateverfunction the user requested.This was a nice scheduling idea for slow I/O bound processes likein the old VAXen days.  This was before RAM cache, prefetch buffers,etc. Also, you didn't have two or more CPUs ready to pounce at anyinstant.Unix, and Unix variants perform kernel functions on behalf of, andin the context of, the caller. You don't lose the CPU just becauseyou called getpid(). However, when the kernel can't do somethingright away (it's I/O bound), you sleep and somebody else gets theCPU. Things done in the kernel are done with kernel privs, butthey are done in the context of a caller.Interrupts just save the caller's registers, load kernel registers,execute an ISR with kernel privs, reload caller's registers, thenreturn to the interrupted task.Cheers,Dick JohnsonPenguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips)."Memory is like gasoline. You use it up when you are running. Ofcourse you get it all back when you reboot..."; Actual explanationobtained from the Micro\$oft help desk.-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgPlease read the FAQ at http://www.tux.org/lkml/`