| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
| |
If a task is released on a CPU that is idle, then it is pointless to
send an IPI to another CPU just to schedule the newly released task.
This patch changes check_for_preemptions() to prefer the local CPU
first if it is idle.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allocating contiguous buffers with kmalloc() is subject to severe
maximum size limits. For Feather-Trace to work, we don't actually need
*physically* contiguous memory; virtually contiguous memory is
sufficient. By switching to vmalloc(), the code gets simpler and we
can support much larger buffers.
For convenience, this patch also adds a configuration option for
the desired Feather-Trace buffer size and increases the default
size.
|
|
|
|
|
|
| |
The 'time_slice' parameter has not been relevant in a couple of years.
The 'completed' flag was misused in a few places. This clean-up patch
removes these outdated remnants.
|
|
|
|
|
|
|
| |
The PFAIR would not properly schedule tasks that were admitted while
being suspended. This patch changes the task_new() handler to set the
"needs to be requeued" flag on suspended tasks, which is required to
ensure that they are processed correctly by the wake_up() handler.
|
|
|
|
|
| |
This patch fixes admission of suspended tasks under the P-FP plugin
analogously to commit 3088111567f334cccff1123f9bd97f2ba52af944.
|
|
|
|
|
|
| |
In the task_new() handler, don't process a job arrival event if the
task is actually suspended. This fixes the admission of suspended
tasks.
|
|
|
|
|
| |
This commit fixes admission of suspended tasks under the P-FP plugin
analogously to commit 78ae3306ff8b63a4592044aa28c2f2cbc1d36b20.
|
|
|
|
|
| |
The PSN-EDF plugin used to crash when trying to admit a suspended
task. This patch fixes the task_new() handler to tolerate this case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...and also finally fix the requeue() race (hopefully).
Commit 4ffefb822b9d65d4efbedb60e3c9a0e76895cc5b broke the synchronous
task system release code. The problem is that release_at() clears the
tsk_rt(t)->completed flag. The patch thus only made the race window
smaller, but didn't close it entirely. Further, it broke the
synchronous task set release, which relies on schedule() being called
with completed == 1.
This patch fixes both problems by introducing a new flag dont_requeue,
which indicates unambiguously that a task should not be requeued by
other processors. This flag is cleared only when the job completion is
being processed, which always happens while holding the appropriate
scheduler locks, which closes the race window.
|
|
|
|
| |
Breaks without do_div() on ARM.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nesting of locks was never supported in LITMUS^RT since
the required analysis does not exist anyway. That is, as
defined in the literature, the protocols implemented
in LITMUS^RT have not been studied in conjunction with
nested critical sections.
In LITMUS^RT, attempting to nest locks could lead to
silent or not-so-silent bugs. This patch makes this
restriction explicit and returns EBUSY when a process
attempts to nest resources.
This is enforced on a protocol-by-protocol basis,
which means that adding protocols with support for
nesting in future versions is not affected by this
change.
Exception: PCP and SRP resources may be nested,
but not within global critical sections.
|
|
|
|
|
| |
When the config parameter is NULL, just default to the local CPU,
which is what we want in 99% of the cases anyway.
|
|
|
|
|
|
| |
Linux tracepoints for real time tasks were causing
compilation errors. For the tracing data structures to be
properly created, it's necessary to add a #define.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
stop_machine() does exactly what we want (avoid all concurrent
scheduling activity) and much simpler than rolling our own (buggy)
implementation.
|
|
|
|
|
|
|
| |
The list is concurrently being modified by the waking processes. This
requires the use of the list_for_each_safe() iterator.
Reported by Glenn Elliott.
|
|
|
|
|
|
|
|
|
|
| |
This patch makes CONFIG_PREEMPT_STATE_TRACE depend on
CONFIG_DEBUG_KERNEL. Prior to this patch, selecting PREEMPT_STATE_TRACE
resulted in linker errors (see below), because sched_state_name is not
built unless DEBUG_KERNEL is selected.
kernel/built-in.o: In function `schedule':
(.sched.text+0x3d2): undefined reference to `sched_state_name'
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
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 a warning about an unused label in sched_pfp.c
when CONFIG_LITMUS_LOCKING is not set.
Signed-off-by: Manohar Vanga <mvanga@mpi-sws.org>
|
|
|
|
| |
No suspended task should ever be queued in this plugin.
|
|
|
|
|
| |
Crash and burn if an expected preemption didn't happen. This is useful
to flag any bugs in the queue management code...
|
|
|
|
| |
It's CONFIG_LITMUS_LOCKING, not just CONFIG_LOCKING...
|
|
|
|
|
|
| |
Make the priority comparison easier to read. Also, remove the "equal
PID" clause and insert a corresponding BUG_ON() instead; this should
really never happen.
|
|
|
|
|
|
| |
boost_priority() is only applied to already-scheduled tasks. Remove
the (untested and unneeded) case handling unscheduled tasks, which was
likely not correct anyway.
|
|
|
|
|
| |
When a job was tardy, the plugin failed to invoke sched_trace. This
caused ugly "holes" in the visualized schedule.
|
|
|
|
|
|
|
| |
The SEND_RESCHED is really only interesting if the IPI was generated
by LITMUS^RT. Therefore, we don't need to trace in Linux's
architecture-specific code. Instead, we hook into the preemption state
machine, which is informed about incoming IPIs anyway.
|
|
|
|
|
|
|
|
|
|
| |
Linux's post_schedule() scheduling class hook more closely matches
what SCHED2 is supposed to trace, namely any scheduling overhead after
the context switch. The prior trace points caught timers being armed
from finish_switch(), which is already included in the context switch
cost CXS.
(This patch essentially reverts 8fe2fb8bb1c1cd0194608bc783d0ce7029e8d869).
|
|
|
|
|
|
|
| |
SEND_RESCHED_END is necessarily preceded by an interrupt. We don't
want to filter events based on this expected interrupts, but we still
want to detect samples disturbed by other interrupts. Hence, subtract
one off the interrupt count.
|
|
|
|
|
|
|
|
|
|
|
| |
If the tracing code is interrupted / preempted inbetween the time that
a sequence number is drawn and the time that the trace recorded is
allocated, then the trace file will contain "out of order" events.
These are difficult to detect during post-processing and can create
artificial "outliers". This patch briefly disables local interrutps to
avoid this.
While at it, de-duplicate the timestamp recording code.
|
|
|
|
|
|
| |
To detect interrupts that interfered after the initial time stamp was
recorded, this patch changes sched_trace to also record the IRQ count
as observed by userspace.
|
|
|
|
| |
Also add some compile-time checks to detect unexpected offsets.
|
|
|
|
|
| |
Support recording timestamps that allow tracing the entry and exit
costs of locking-related system calls.
|
|
|
|
|
| |
Reassing locking timestamps and prepare support for tracing
system call overheads.
|
|
|
|
|
|
|
|
| |
To properly trace locking overheads, it is required to tell apart
samples from different tasks, which requires keeping track of their
PIDs.
The timestamp is shortened to 48 bits to make room for the PID.
|
|
|
|
| |
Holding the lock prevents other tasks from opening the device.
|
|
|
|
|
|
|
| |
When a task exists and its FDSO table is released, the locking
protocol's 'close()' callback should be invoked to do proper
protocol-specific cleanup (such as unlocking the resource, if
required).
|
|
|
|
|
|
|
|
|
| |
The old implementation had the problem that the first job release of all
tasks was handled on the *same* CPU (that triggered the synchronous task set
release). This could result in significant latency spikes.
The new implementation uses a completion per task. Futher, each task programs
its own release, which ensures that it will be on the proper processor.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Restructured the EDF task comparison code to improve readability.
Recoded chained logical expression embedded in return statement
into a series of if/else blocks.
|
| |
|