| Commit message (Collapse) | Author | Age |
|
|
|
| |
Signed-off-by: Christopher Kenna <cjk@cs.unc.edu>
|
|
|
|
| |
Signed-off-by: Christopher Kenna <cjk@cs.unc.edu>
|
|
|
|
|
|
|
|
| |
Conflicts:
include/litmus/color.h
Signed-off-by: Christopher Kenna <cjk@cs.unc.edu>
|
| |
|
|
|
|
|
|
| |
This is not tested and probably won't work.
Signed-off-by: Christopher Kenna <cjk@cs.unc.edu>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Try and fix the cycle counter on ARMv7 CPUs (unsuccessful).
Use the multi-core timer on the ODROID-X to count cycles.
Add lockdown register access to proc.
Add proc options to disable prefetching for L1/L2 cache.
Add test to lockdown.c to print the time to read in various WSSs.
Signed-off-by: Christopher Kenna <cjk@cs.unc.edu>
|
|
|
|
| |
This commit is dirty and will be cleaned up when blocking states are tested.
|
| |
|
| |
|
|\ |
|
| | |
|
|/
|
|
|
|
|
|
| |
Conflicts:
arch/arm/mm/cache-l2x0.c
Signed-off-by: Christopher Kenna <cjk@cs.unc.edu>
|
|
|
|
| |
Currently is always preempting. This needs to be configurable via proc.
|
|\
| |
| |
| | |
wip-mc
|
| |
| |
| |
| |
| |
| |
| |
| | |
Commit e6f51fb826ce98d436f445aae4eb9e9dba1f30e8 added some floating
point support for LITMUS^RT, but it used 64-bit division that ARM does
not support. Therefore, use the division functions from math64.h.
Signed-off-by: Christopher Kenna <cjk@cs.unc.edu>
|
| |
| |
| |
| | |
Signed-off-by: Christopher Kenna <cjk@cs.unc.edu>
|
| |
| |
| |
| | |
Signed-off-by: Christopher Kenna <cjk@cs.unc.edu>
|
| |
| |
| |
| | |
Signed-off-by: Christopher Kenna <cjk@cs.unc.edu>
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While working on an ODROID-X (Samsung Exynos4412 ARM Cortex-A9), I
experienced non-determinism when reading and writing values to the
LITMUS^RT control page. Writes to the control page from user- (kernel-)
space where not always reflected in kernel- (user-) space.
Neither restricting the task to run on a single CPU nor inserting
general memory barriers (with mb()) fixed the problem. Mapping the
control page as uncachable in both kernel and user space did fix the
problem, which is what this patch does.
Also, since vunmap() cannot be called from an interrupt context, I had
to add a workqueue that unmaps and frees the control page when it is no
longer needed. (On my system, exit_litmus() was called from interrupt
context while the kernel reaped the task_struct.)
Conflicts:
include/litmus/rt_param.h
litmus/litmus.c
Does not make the color control page uncachable yet!
Signed-off-by: Christopher Kenna <cjk@cs.unc.edu>
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Both sched_color and sched_mc assumed seperate kernel and userspace views of job
states, where the kernel view is used for scheduling while the userspace view
is used for statistics (tardiness etc). This commit merges both approaches.
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
include/litmus/rt_param.h
litmus/sched_color.c
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
include/litmus/rt_param.h
litmus/jobs.c
litmus/sched_color.c
litmus/sched_task_trace.c
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
include/litmus/rt_param.h
litmus/sched_color.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.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Added support for arbitrary deadlines.
Constraint: Relative deadline must be >= exec cost.
Use: Set relative deadline in rt_task::rdeadline. Set value to 0
to default to implicit deadlines.
Limitations: PFAIR not supported by this patch. PFAIR updated to
reject tasks that do not have implicit deadlines.
|
| |
| |
| |
| |
| |
| | |
Add a comment to explain how priorities are
interpreted, and provide some useful macros for
userspace.
|
| |
| |
| |
| | |
Prior to that it was only used internally for DPCP
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
dissertation (branch bbb-diss) to current
version of litmus
This is needed for ongoing projects
I took the unchanged code but removed some leftovers
of OMLP which is not implemented
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch changes how preemptions of jobs without
budget work. Instead of requeuing them, they are now
only added if they are not subject to budget enforcement
or if they have non-zero budget. This allows us to process
job completions that race with preemptions.
This appears to fix a BUG in budget.c:65 reported by Giovani Gracioli.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
litmus.h is accumulating too many things. Since
we already have budget.h, let's stick all budget-related
inline functions there as well.
This patch is merely cosmetic; it does not change
how budget enforcement works.
|
| |
| |
| |
| |
| |
| |
| | |
An efficient binary heap implementation coded in the
style of Linux's list. This binary heap should be able
to replace any partially sorted priority queue based
upon Linux's list.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Enable kernel-style events (tracepoint) for Litmus. Litmus events
trace the same functions as the sched_trace_XXX(), but can be
enabled independently.
So, why another tracing infrastructure then:
- Litmus tracepoints can be recorded and analyzed together (single
time reference) with all other kernel tracing events (e.g.,
sched:sched_switch, etc.). It's easier to correlate the effects
of kernel events on litmus tasks.
- It enables a quick way to visualize and process schedule traces
using trace-cmd utility and kernelshark visualizer.
Kernelshark lacks unit-trace's schedule-correctness checks, but
it enables a fast view of schedule traces and it has several
filtering options (for all kernel events, not only Litmus').
|
| | |
|