| 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).
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
Allow tracing of NULL tasks. Makes debugging a bit easier.
|
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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!
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes two bugs with nested locks:
1) List of aux threads could become corrupted.
-- moved modifications to be within scheduler lock.
2) Fixed bad EDF comparison ordering that could lead
to schedule thrashing in an infinite loop.
3) Prevent aux threads from inheriting a priority from
a task that is blocked on a real-time litmus lock.
(since the aux threads can't possibly hold these locks,
we don't have to worry about inheritance.)
|
| |
| |
| |
| |
| |
| | |
Auxillary task features were enabled by CONFIG_LITMUS_LOCKING.
Made auxillary tasks a seperate feature that depends upon
CONFIG_LITMUS_LOCKING.
|
| | |
|
| | |
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
include/litmus/unistd_32.h
include/litmus/unistd_64.h
litmus/litmus.c
|
| | | |
|
| | |\
| | | |
| | | |
| | | |
| | | | |
Conflicts:
litmus/sched_gsn_edf.c
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Added signals to Litmus. Specifcally, SIG_BUDGET signals
are delivered (when requested by real-time tasks) when
a budget is exceeded.
Note: pfair not currently supported (but it probably could be).
|
| | |\ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
include/litmus/binheap.h
include/litmus/fdso.h
include/litmus/litmus.h
litmus/Makefile
litmus/binheap.c
litmus/edf_common.c
litmus/fdso.c
litmus/jobs.c
litmus/locking.c
|
| | | |/
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead of tie-breaking by PID (which is a static
priority tie-break), we can tie-break by other
job-level-unique parameters. This is desirable
because tasks are equaly affected by tardiness
since static priority tie-breaks cause tasks
with greater PID values to experience the most
tardiness.
There are four tie-break methods:
1) Lateness. If two jobs, J_{1,i} and J_{2,j} of
tasks T_1 and T_2, respectively, have equal
deadlines, we favor the job of the task that
had the worst lateness for jobs J_{1,i-1} and
J_{2,j-1}.
Note: Unlike tardiness, lateness may be less than
zero. This occurs when a job finishes before its
deadline.
2) Normalized Lateness. The same as #1, except
lateness is first normalized by each task's
relative deadline. This prevents tasks with short
relative deadlines and small execution requirements
from always losing tie-breaks.
3) Hash. The job tuple (PID, Job#) is used to
generate a hash. Hash values are then compared.
A job has ~50% chance of winning a tie-break
with respect to another job.
Note: Emperical testing shows that some jobs
can have +/- ~1.5% advantage in tie-breaks.
Linux's built-in hash function is not totally
a uniform hash.
4) PIDs. PID-based tie-break used in prior
versions of Litmus.
Conflicts:
litmus/edf_common.c
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |/
| |/| |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch removes the RT_F_EXIT_SEM flag. All code paths
depending on it being true are assumed to be unreachable
and removed.
The 'flags' field in struct rt_params is left as-is for
use by specific schedulers. For example, sched_pfair
defines a custom flag RT_F_REQUEUE within the 'flags'
field.
Signed-off-by: Manohar Vanga <mvanga@mpi-sws.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch removes the flags RT_F_SLEEP and RT_F_RUNNING
as their name is misleading. This patch replaces them with
a 'completed' field in struct rt_param.
Signed-off-by: Manohar Vanga <mvanga@mpi-sws.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch fixes the compiler warning about struct litmus_locking
being defined in the parameter list when CONFIG_LITMUS_LOCKING is
not set.
Signed-off-by: Manohar Vanga <mvanga@mpi-sws.org>
|
| | |
| | |
| | |
| | | |
Stop hard-to-detect out-of-bounds errors early.
|