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

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