lkml.org 
[lkml]   [2000]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [RFC] Implementing temporal affinity
Date


> -----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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.063 / U:3.696 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site