* tasking priorities
@ 1988-02-05 1:10 Michael Murphy
0 siblings, 0 replies; 2+ messages in thread
From: Michael Murphy @ 1988-02-05 1:10 UTC (permalink / raw)
There recently has been much discussion about preemptive schedulers and
the interpretation of LRM 9.8(4). I think I understand what it means for
the normal uniprocessor machine, but I'm not clear on its interpretation
for multiprocessor and distributed machines. AI-00032 notes that:
(Note: the phrase "could sensibly be executed" refers to situations in which
the high priority task can actually make use of the processor and other
resources being used by the lower priority task. In some distributed
processing situations, a high priority task may not be able to execute on
some processors. Preemption is only required for processing resources the
high priority task can use.)
What if the processor the high priority task is currently located on cannot
run the task, but there is another processor "nearby" that could run it?
My question is, must the new high-priority task migrate to the
processor (able to run the new task) where the lowest priority task
is running (which would mean polling all processors on the system)?
It would be much more efficient and would appear to be in the "spirit"
of tasking priorities to only preempt the tasks running on your local machine.
Comments? Anybody have a definitive ruling on this?
Note that this question can be applied separately (possibly with different
answers) to both distributed and multiprocessing machines.
-- michael murphy
-- UUCP: {uunet|sun}!elxsi!elk!murphy
-- AT&T: 408-942-0900
^ permalink raw reply [flat|nested] 2+ messages in thread
* tasking priorities
@ 1988-02-19 0:59 Michael Murphy
0 siblings, 0 replies; 2+ messages in thread
From: Michael Murphy @ 1988-02-19 0:59 UTC (permalink / raw)
I posted (or at least thought I did) the following a couple weeks ago
and never got any response. I'm posting it again in case it never made
it to the net. I apologize in advance if this is redundant.
--------------------------------------------------------------------------
There recently has been much discussion about preemptive schedulers and
the interpretation of LRM 9.8(4). I think I understand what it means for
the normal uniprocessor machine, but I'm not clear on its interpretation
for multiprocessor and distributed machines. AI-00032 notes that:
(Note: the phrase "could sensibly be executed" refers to situations in which
the high priority task can actually make use of the processor and other
resources being used by the lower priority task. In some distributed
processing situations, a high priority task may not be able to execute on
some processors. Preemption is only required for processing resources the
high priority task can use.)
What if the processor the high priority task is currently located on cannot
run the task (perhaps there is a higher priority task already running on it),
but there is another processor "nearby" that could run it?
My question is, must the new high-priority task migrate to the
processor (able to run the new task) where the lowest priority task
is running (which would mean polling all processors on the system)?
It would be much more efficient and would appear to be in the "spirit"
of tasking priorities to only preempt the tasks running on your local machine.
Comments? Anybody have a definitive ruling on this?
Note that this question can be applied separately (possibly with different
answers) to both distributed and multiprocessing machines.
-- michael murphy
-- UUCP: {uunet|sun}!elxsi!elk!murphy
-- AT&T: 408-942-0900
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1988-02-19 0:59 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1988-02-05 1:10 tasking priorities Michael Murphy
-- strict thread matches above, loose matches on Subject: below --
1988-02-19 0:59 Michael Murphy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox