[Beowulf] preemptive kernel and preemptive schedulers
toon.knapen at fft.be
Mon Jun 25 00:48:44 PDT 2007
To me the difference is that a (or all) scheduler will not be able to
'continue' (and thus migrate) the job it preempted on any of the cpu's
available to the scheduler.
You might find more info on this in this thread:
Mark Hahn wrote:
>> RT Linux (I am a newbie to RT=Linux) is based on the concept of
>> Preemptive kernels where the jobs are
>> temporally preempted say a FIFO scheduler implemented at the kernel
> when people say "RT Linux", they normally mean various flavors of
> hard-RT hacks (not meant in an entirely disparaging way;)
> on such systems, it much more than simply suspending user-space - back
> in the
> day, the idea of preempting the whole kernel was extremely controversial.
> my impression is that since then, the (real, kernel.org kernel) has
> become drastically more predictable in latency, and in many ways more
> even ~6 years ago, it was quite feasible to run realtime applications on
> the kernel.org kernel - I did realtime video generation and response
> timing for psychophysics labs. it wasn't hard-RT in the sense of
> "provably always meets all deadlines", but for a lab, it just worked...
>> I know that the same is achieved by submitting the job through a job
>> scheduler(ca. PBS Pro) installed
>> on top of the OS.
> a job scheduler is entirely different from hard-RT stuff. a job
> scheduler is
> primarily concerned with managing cluster resources, which may indeed
> include suspending jobs. at least the conventional ones like
> PBS/LSF/etc are most
> definitely _not_ hard-RT - if nothing else, they tend to respond on the
> of several seconds, not microseconds...
>> I wanted to know whether schedulers can be alternatives for preemptive
> sure. in the most abstract sense, they are the same. the original RTLinux
> stuff was based on an executive/hypervisor which preempted the kernel
> much as a normal job scheduler might preempt a job. these days, the
> boundaries are further blurred by virtualization...
> regards, mark hahn.
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit
More information about the Beowulf