From: "Chris Swiedler" <ceswiedler@mindspring.com>
> > 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.
But it is. It's run long enough to load the CPU cache with it's own
instructions and data. Since you are trying to preserve the CPU cache,
you want it to run again instead of something else. Right?
>From the original post:
From: "Chris Swiedler" <ceswiedler@mindspring.com>
> Dmitris Michailidis recently mentioned a desire to have the kernel
implement
> temporal affinity, where a process which is briefly interrupted has a
better
> chance of being scheduled. The idea would be that if the interrupting
> process ran briefly enough, the CPU cache would still contain
> instructions/data from the previous process.
Process B in my example is the process that is briefly interrupted. It
should reschedule onto the same cpu right away. But it doesn't.
> 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.
But you *do* want it to get tied to the CPU since it's "stuff" is in the
CPU cache. Right?
In fact, isn't last_cpu doing time affinity already? Except in the case
where
there are more than one processes that have the same last_cpu. Then
you have to figure out how to choose the most recent one.
> 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?
I think I understand what you're trying to do, but at the same time
if I do we should agree. So I'm probably misunderstanding something.
..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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:16 EST