| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First 'working' implementation of DGLs with PRIOQ_MUTEX.
(All other code prior was work-in-progress.)
General approach:
Because of priority queue order, PRIOQ_MUTEX DGLs must be
*acquired* atomically. This means that a task cannot
acquire an available PRIOQ_MUTEX if another PRIOQ_MUTEX
is not available at the same time. Requests are buffered
in PRIOQ_MUTEX and the resource 'idles'-- that is, the
mutex owner is NULL, but there are waiting tasks for the
resource.
Several notes/side-effects:
1) A high-priority task that idles a resource can
effectively block lower-priority tasks from acquiring
that resource. This is because the low-prio task
cannot skip ahead of the high-prio task in the priority
queue.
2) Priority inheritance from nesting can cause the
low-prioity task in #1 to jump over the high-priority
task and acquire the resource. This means that
any task blocked on a DGL that receives an increase
in priority while blocked on the DGL must trigger
a re-eval of the locks it can take. If the resources
can be acquired, then the task needs to be woken
up! <<<<< Lock acquisition via inheritance is entirely
new and weird! >>>>>
3) A similar case for #2 exists for priorty decreases
(example: this can happen when a task loses a donor)
while it is blocked on a PRIOQ_MUTEX. The high-priority
task described in #1 can change and become a lower-
priority task. Every idle lock (mutex owner is NULL)
on which the task losing priority must be revaluated---
it is possible that the (possible) new head on the
priority queue can take the lock. Note: This affects
BOTH singular and DGL resource requests, while
the case described in #2 only affects DGL requests
(because a singular request at the head of the priority
queue will never idle a resource).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| | |
In some cases, the PCP priority inheritance code triggered a
(defensive) BUG_ON() in fp_common.c. This shuffles the order of
operations a bit to be compliant with the restriction that tasks are
never compared against themselves.
|
| | |
| |
| |
| | |
Prevents out-of-bounds lookups.
|
| | |
| |
| |
| | |
Allow tracing of NULL tasks. Makes debugging a bit easier.
|
| | | |
|
| | |
| |
| |
| |
| | |
Tasks that immediatly acquired a free replica
were not being counted as being in the FIFOs.
|
| | |
| |
| |
| |
| |
| | |
IKGLP wasn't being passed the right value for
'm' in C-EDF. It went undected for so long
since m < k in our GPUSync experiments.
|
| | |
| |
| |
| |
| | |
fixed minor bugs and cleaned up
ikglp affinity logic
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Bug: Inheritance not propagated to klmirqd and aux
tasks when the task these threads inherit from
has a change in its own priority.
(Also removed per-task NV interrupt tracking since
we cannnot identify exact interrupt ownership under
GPUSync.)
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixed bug where AUX tasks were being added to the
ready queue while those AUX tasks were actually blocked.
Bug stems from the fact that the AUX tasks do not
make themselves realtime, but another thread does this
instead. Also fixed minor bugs elsewhere.
NOTE: ONLY FIXES C-EDF. OTHER PLUGINS REMAIN TO BE FIXED.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
RSM locks only make use of /proc for now.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
include/litmus/fpmath.h
include/litmus/litmus.h
include/litmus/rt_param.h
include/litmus/trace.h
kernel/sched.c
kernel/softirq.c
litmus/edf_common.c
litmus/jobs.c
litmus/litmus.c
litmus/locking.c
litmus/preempt.c
litmus/sched_cedf.c
litmus/sched_gsn_edf.c
litmus/sched_litmus.c
litmus/sync.c
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Note that non-rt tasks are released immediately. That is,
the 'delay' provided to the release_ts() system-call is ignored
for non-rt tasks.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1) Deadlock in litmus_task_exit()-- added litmus_pre_task_exit()
to be called without the Linux runqueue lock held.
2) Prioritization of base-prio klmirqd/aux threads vs. normal
real-time tasks.
3) Initialization of gpu owner binheap node moved to *after*
memset(0) of rt_params.
4) Exit path of klmirqd threads.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Note that num_online_gpus() merely reports the
staticly configured maximum number of available
GPUs. Will make dynamic in the future.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
this code is untested!
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch causes reboot notifications to be send
to Litmus. With this patch, Litmus attempts to
switch back to the Linux-plugin before the reboot
proceeds. Any failures to switch back are reported
via printk() (the reboot is not halted).
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |\ \ |
|
