| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
| |
Patched using Namhoon's implementation of reservation for MC^2 to
support global multiprocessor scheduling.
Patched compiler-gcc5 to support gcc v5 compiler.
Bug fixed regarding user input big cpu id number causing kernel crash.
|
|
|
|
|
| |
Don't set a release timer for jobs that are tardy and already
released.
|
|
|
|
|
|
| |
Don't forget to ask for a scheduler update when a reservation is
replenished but enters state ACTIVE_IDLE and there's nothing else
going on that triggers the scheduler by chance.
|
|
|
|
|
|
| |
Keep track of the current slot and major cycle explicitly to avoid
ambiguity when the budget charging is delayed into the next major
cycle due to a late interrupt or other sources of delay.
|
|
|
|
|
| |
Checking state->scheduled is not accurate when bandwidth inheritance
is applied.
|
|
|
|
|
|
|
| |
The P-RES plugin is currently not compatible with the per-thread
budget enforcement logic, which can trigger assertion failures. For
now, let's simply disable per-thread timeslice enforcement. (P-RES's
reservations are a much better mechanism anyway.)
|
|
|
|
|
|
| |
The kernel codepath calling into pres_admit_task() is holding some
lock unrelated to LITMUS^RT. As a result, we need to pass GFP_ATOMIC,
not just GFP_KERNEL, to kzalloc().
|
|
|
|
|
|
|
| |
Rationale: the internal priority point representation is of type lt_t
(64 bits), so to enable userspace to specify priorities below (=after)
EDF priority points, we need to allow userspace to specify values
larger than 2^32.
|
|
|
|
| |
This can be a useful stat for userspace.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a rare condition under which the current call to hrtimer_start()
in pres_update_timer() may result in deadlock.
pres_update_timer() // holds runqueue lock and state->lock
-> hrtimer_start()
-> raise_softirq_irqoff()
-> wakeup_softirqd()
-> wake_up_process()
-> acquires runqueue lock()
To avoid this, we need to call __hrtimer_start_range_ns() with the
'wakeup' flag set to zero.
While at it, also drop the state->lock before calling into hrtimer(),
to avoid making the scheduler critical section longer than necessary.
|
|
|
|
|
|
| |
This makes it a lot easier to write generic code for thread arrival /
thread departure in plugins with multiple types of reservation
clients.
|
|
|
|
|
|
| |
Make sure we don't accidentally bleed past the current reservation
scheduling slot (due to jitter) by determining the remaining budget
precisely when replenishing the reservation budget.
|
|
|
|
|
|
| |
Accidentally setting up the timer on the wrong CPU when a thread
resumes is problematic can lead (potentially) to deadlock and to
missed scheduling events.
|
|
|
|
|
| |
Instead of counting how much budget has been consumed, determine
budget based on actual time slots.
|
| |
|
|
|
|
|
|
| |
A simple partitioned scheduler that provides a reservation environment
on each core, based on the generic reservations code. Hierarchical
scheduling is not supported in this version.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Instead of calling complete_job() directly, the default implementation
of wait_for_release_at() should invoke the plugin-provided
complete_job() method to support plugins that happen to override
complete_job(), but not wait_for_release_at().
|
|
|
|
|
|
|
|
|
|
| |
Without a proper release time, the job will be considered "lagging
behind" for quite a while, which breaks the period enforcement. This
bug manifested only in the absence of a synchronous release (which set
a proper release time).
This patch simply sets the beginning of the next quantum as the
release time of the first job of a newly added task.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Assigning a nice value to LITMUS^RT tasks is meaningless. Bail out
early.
|
|
|
|
|
| |
This patch fixes a BUG_ON() in litmus/preempt.c:33 reported by Felipe
Cerqueira & Manohar Vanga.
|
|
|
|
|
|
| |
The rt scheduling class thinks it's the highest-priority scheduling
class around. It is not in LITMUS^RT. Don't go preempting remote cores
that run SCHED_LITMUS tasks.
|
| |
|
|
|
|
|
|
| |
LITMUS^RT plugins like to know who 'prev' is. pick_next_task() doesn't
expose that info, so we just cache prev in the runqueue. Could robably
be replaced by looking at 'current' instead.
|
|
|
|
| |
To keep track of stack usage and to notify plugin, if necessary.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Global plugins require that the plugin be called even if there
currently is no real-time task executing on the local core.
|
| |
|
|
|
|
|
|
| |
Needs to be above stop_machine_class for legacy reasons; the main
plugins were developed before stop_machine_class was introduced and
assume that they are the highest-priority scheduling class.
|
| |
|
| |
|
|
|
|
| |
Check whether a suspension is required at end of schedule().
|
|
|
|
| |
This patch adds context switch tracing to the main Linux scheduler.
|
|
|
|
|
|
|
|
|
|
|
| |
Whenever the kernel checks for rt_task() to avoid delaying real-time
tasks, we want it to also not delay LITMUS^RT tasks. Hence, most
calls to rt_task() should be matched by an equivalent call to
is_realtime().
Notably, this affects the implementations of select() and nanosleep(),
which use timer_slack_ns when setting up timers for non-real-time
tasks.
|
|
|
|
|
| |
Allow LITMUS^RT to do some work when a process is created or
terminated.
|