Messages in this thread |  | | From | "Stuart MacDonald" <> | Subject | Re: [RFC] Implementing temporal affinity | Date | Fri, 25 Aug 2000 15:26:03 -0400 |
| |
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.
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?
..Stu
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |