| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
| |
Comparing a task against itself shouldn't
happen if everything works correctly.
|
|
|
|
|
|
| |
If the first argument to edf_higher_prio is NULL, then just
return 0, since it can't possibly have a higher piority than the
second argument.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of having hrtimers for each task, we now have only
one hrtimer per rt_domain. To-be-released tasks are grouped in
mergable heaps and presented as a bunch on each release.
This approach should allow us to reduce the worst-case overhead
at hyperperiod boundaries significantly.
1) less hrtimer overhead
2) less calls to the active plugin
3) only one CPU handles releases at a time
4) (2) & (3) should bring down lock contention significantly
|
|
|
|
|
|
| |
The list-based priority queues did not perform well on the Niagara T2000.
This heap-based implementation should perform much faster when queues
are long.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
litmus/edf_common.c
litmus/sched_gsn_edf.c
litmus/sched_psn_edf.c
Minor clashes between sched_clock() -> litmus_clock() and jobs.c refactoring
merged by hand. The result has been compile-tested.
|
| |
| |
| |
| | |
John's proposal for how to release jobs with hrtimers.
|
|/ |
|
|
This introduces the core changes ported from LITMUS 2007.
The kernel seems to work under QEMU, but many bugs probably remain.
|