Messages in this thread |  | | From | "Chris Swiedler" <> | Subject | RE: [RFC] Implementing temporal affinity | Date | Fri, 25 Aug 2000 15:37:23 -0400 |
| |
> -----Original Message----- > From: Stuart MacDonald [mailto:stuartm@connecttech.com] > Sent: Friday, August 25, 2000 2:43 PM > To: Chris Swiedler; linux-kernel@vger.kernel.org > Subject: Re: [RFC] Implementing temporal affinity > > > 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.
B only ran for 15 cycles, and therefore it ISN'T the time-affinity process. That's the whole point: if a process doesn't run for N cycles, it doesn't get tied to the CPU. If B HAD run for >50 cycles, and been interrupted, then its last_cpu would be 2.
I think a better way to do it would be to keep a per-CPU pointer to the last task to run. That way, no more than one process "owns" a CPU. If we keep it like this, then if A then B both run on CPU2 for >50 cycles, then both have last_cpu of 2. Isn't there a cpu_struct somewhere where we could store a last_task pointer?
chris
- 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/
|  |