| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
Support for process-aware interrupt handling was broken
when the tasklet ownership model changed in GPUSync,
post-ECRTS12. We will want to re-add support later,
but remove it for now.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
a very ugly kludge. wake ups are queued in
a per-cpu buffer. lock, unlock, and budget
operations that affect priority then have to
flush the wake queue.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
New budget drain policy drains while task is executing
or suspends for a non-litmus-lock (non-real-time, such
as for I/O) reason.
|
|
|
|
|
|
| |
Also added logic for real-time tasks to prevent
worker threads (klmirqd and aux tasks) from inheriting
from tasks waiting for release.
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
include/litmus/budget.h
litmus/sched_cedf.c
litmus/sync.c
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Fixed a major bug where a scheduled task with
and exhausted budget does not recheck its priority
inheritance upon deadline postponement. Postponment
may enable priority inheritance relations, as the
priority of the lock holder decreases.
|
| | |
|
| |
| |
| |
| |
| | |
Fixes bug that failed to move new requests to the FIFO
queue after an aborted request in a FIFO makes room.
|
| |
| |
| |
| |
| |
| |
| | |
Added support to IKGLP to handle budget exhaustion
of blocked waiter.
NOTE: CODE IS UNTESTED...
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixed bug whereby the budget timer could fire and be handled
on a remote CPU while a task is waking up. Thus, the handler
runs the 'is-running' branch of logic and triggers a remote
resched. In the meantime, the target task runs and blocks.
Thus, the budget is not refreshed in the resched routine
because the task is both out of budget AND blocked.
The fix: In the on_blocked routine, re-arm the timer. This will
re-run the exhaustion logic.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Adds a configuration option to allow the ready queue
to be a recursive (raw) spinlock. This is useful
in implementing inheritance from nested locking
and budget enforcement actions.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds an implementation of recursive spinlocks.
These allow a lock to be taken repetitively in a nested
fastion by the same CPU, provided that every lock call
is matched with an unlock call.
In general, the use of recursive locks IS TO BE
DISCOURAGED. However, it can make some implementation
easier. Try to only use recursive spinlocks as a
stop-gap measure in software development.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Proper sobliv draining: Always and only drain budget
from a task if its BASE priority is among the top
m processors in the cluster. This required some
work with timers and tracking of consumed budget
while a task is suspended (since the Linux rq won't
track this for us).
Had to introduce a number of hacks and kludges to
make this work in the required timeframe:
1) C-EDF's ready queue lock becomes recursive (yuck!)
2) Extend bheap with a for_each visitor function.
This is needed to set a timer for each newly released
job.
3) Dual-binary heap structure in C-EDF to divide
jobs into top-m and not-top-m tasks.
4) Restructured the budget plugin API. Unfortunatly,
there is not a lot of overlap between SIMPLE and
SOBLIV draining policies.
|
| |
| |
| |
| | |
Also fixed numerous bugs...
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Adds support for suspension-oblivous budget draining
to C-EDF. Also changes how jobs with exhausted budget
in C-EDF are treated: jobs are early released until
they catch up.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As a step towards implementing more complex budget tracking
method (ex. BWI, VXR, etc.), we need per-task budget trackers
because we may be required to drain budget from a task, even
while it is suspended or blocked.
This patch does:
1) Replaces the per-CPU hrtimers with per-task hrtimers.
2) Plugin architecture for different budget policies.
This patch creates three budget draining policies:
SIMPLE, SAWARE (suspension-aware), and SOBLIV (suspension-oblivious).
However, only SIMPLE is supported by this patch.
SIMPLE (default):
Budget drains while the task is scheduled. Budget is preserved
across self-suspensions (but not job completions, of course).
Only SIMPLE is supported in this patch. (Maintaining current Litmus
functionality.)
SAWARE:
Draining according to suspension-aware analysis. Budget should drain
whenever a task is among the top-m tasks in its cluster, where
m is the number of processors in said cluster. This draining should
happen whether or not the task is actually scheduled.
SOBLIV:
Draining according to suspension-oblivious analysis. Budget should
drain whenever the task is scheduled or suspended (but not due to
preemption). Exception: Draining should halt when we can prove that
the task is not among the top-m tasks blocked on the same lock (i.e.,
on the PQ in the OMLP-family locking protocols).
|
| | |
|
| |
| |
| |
| |
| | |
Remove lock proc entries on lock destruction, not
lock close.
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
include/litmus/litmus.h
include/litmus/rt_param.h
litmus/Makefile
litmus/sched_cedf.c
litmus/sched_gsn_edf.c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Tasks can now be PERIODIC or SPORADIC.
PERIODIC tasks do not have their job number incremented
when they wake up and are tardy. PERIODIC jobs must
end with a call to sys_complete_job() to set up their next
release. (Not currently supported by pfair.)
SPORADIC tasks _do_ have their job number incremented when
they wake up and are tardy. SPORADIC is the default task
behavior, carrying forward Litmus's current behavior.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch allows a task to request early releasing
via rt_task parameters to sys_set_task_rt_param().
Note that early releasing can easily peg your CPUs
since early-releasing tasks never suspend to wait for
their next job. As such, early releasing is really
only useful in the context of implementing bandwidth
servers, interrupt handling threads (or any thread that
spends most of its time waiting for an event), or
short-lived computations. If early releasing pegs your
CPUs, then you probably shouldn't be using it.
|
| |
| |
| |
| |
| |
| |
| |
| | |
cedf_admit_task() is too restrictive in that the task
to be admitted must be executing on the same CPU as
is set in the task's task_params. This patch allows
the task to be admitted to be executing on the same
cluter as the CPU set in the task's task_params.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch creates a new character device, uncachedev.
Pages of RAM allocated by this device are not cached by
CPUs.
Uses for such pages:
1) Determining *very* pessimistic emperical worst-
case execution times.
2) Compare against performance with caches (quantify
the avg. case benefit).
3) Deterministic memory accesses (access cannot cause a
cache eviction.)
4) Theoretically, increased performance can be achieved
by storing infrequently accessed data in uncache pages.
uncachedev allocates pages with the pgprot_noncached() page
attribute for user applications. Since pages allocated by
uncachedev are not locked in memory by default, applications
with any access level may mmap pages with uncachedev.
Limitations:
1) Uncache pages must be MAP_PRIVATE.
2) Remapping not supported.
Usage (user level):
int size = NR_PAGES*PAGE_SIZE;
int fd = open("/dev/litmus/uncache", O_RDWR);
char *data = mmap(NULL, size, PROT_READ | PROT_WRITE,
MAP_PRIVATE, fd, 0);
<...do stuff...>
munmap(data, size);
|