litmus-rt.git/kernel, branch wip-kernthreads The LITMUS^RT kernel. Extract NVIDIA device number (GPU #) from NVIDIA tasklet data. Also 2011-02-27T01:00:15+00:00 Glenn Elliott gelliott@cs.unc.edu 2011-02-27T01:00:15+00:00 0e6a634b0b02a86c9591c1bf8c73ff0cf68475fc added support to fully thread all softirqs. 
added support to fully thread all softirqs.
First working version of klitirqd. 2011-02-13T01:42:53+00:00 Glenn Elliott gelliott@cs.unc.edu 2011-02-13T01:42:53+00:00 08b72aceacca166015d518738f9e300546b969ef Tasklets can be scheduled to klitirqd daemons when provided a real-time task "owner". A klitirqd kernel thread will assume the priority of the owner and will execute the provided tasklet when the kernel thread is scheduled by Litmus. See litmus_softirq.h for interface and limitations. 
Tasklets can be scheduled to klitirqd daemons when provided
a real-time task "owner".  A klitirqd kernel thread will
assume the priority of the owner and will execute the
provided tasklet when the kernel thread is scheduled
by Litmus.

See litmus_softirq.h for interface and limitations.
Litmus core: replace FMLP & SRP system calls with generic syscalls 2011-02-01T21:30:39+00:00 Bjoern B. Brandenburg bbb@cs.unc.edu 2011-01-28T21:41:16+00:00 cc602187d4466374bca031039e145aa1b89aca96 This renders the FMLP and SRP unfunctional until they are ported to the new locking API. 
This renders the FMLP and SRP unfunctional until they are ported to
the new locking API.
bugfix: don't let children stay Litmus real-time tasks 2011-01-30T19:31:56+00:00 Bjoern B. Brandenburg bbb@cs.unc.edu 2011-01-30T01:31:57+00:00 904531a6321964579ab0972a8833616e97dbf582 It has always been LITMUS^RT policy that children of real-time tasks may not skip the admissions test, etc. This used to be enforced, but was apparently dropped during some port. This commit re-introduces this policy. This fixes a kernel panic that occurred when "real-time children" exited without proper initilization. 
It has always been LITMUS^RT policy that children of real-time tasks
may not skip the admissions test, etc. This used to be enforced, but
was apparently dropped during some port. This commit re-introduces
this policy.  This fixes a kernel panic that occurred when "real-time
children" exited without proper initilization.
Workaround: do not set rq->skip_clock_update 2010-11-11T23:00:33+00:00 Bjoern B. Brandenburg bbb@cs.unc.edu 2010-11-11T21:54:20+00:00 6fbc3b495cccf2e4ab7d4ab674b5c576e9946bed Disabling the clock update seems to be causing problems even in normal Linux, and causes major bugs under LITMUS^RT. As a workaround, just disable this "optimization" for now. Details: the idle load balancer causes tasks that suspsend to be marked with set_tsk_need_resched(). When such a task resumes, it may wrongly trigger the setting of skip_clock_update. However, a corresponding rescheduling event may not happen immediately, such that the currently-scheduled task is no longer charged for its execution time. 
Disabling the clock update seems to be causing problems even in normal
Linux, and causes major bugs under LITMUS^RT. As a workaround, just
disable this "optimization" for now.

Details: the idle load balancer causes tasks that suspsend to be
marked with set_tsk_need_resched(). When such a task resumes, it may
wrongly trigger the setting of skip_clock_update. However, a
corresponding rescheduling event may not happen immediately, such that
the currently-scheduled task is no longer charged for its execution
time.
Implement proper remote preemption support 2010-11-11T22:57:44+00:00 Bjoern B. Brandenburg bbb@cs.unc.edu 2010-11-10T17:10:49+00:00 fb3df2ec261d8cd6bcb8206d9d985355214d7767 To date, Litmus has just hooked into the smp_send_reschedule() IPI handler and marked tasks as having to reschedule to implement remote preemptions. This was never particularly clean, but so far we got away with it. However, changes in the underlying Linux, and peculartities of the ARM code (interrupts enabled before context switch) break this naive approach. This patch introduces new state-machine based remote preemption support. By examining the local state before calling set_tsk_need_resched(), we avoid confusing the underlying Linux scheduler. Further, this patch avoids sending unncessary IPIs. 
To date, Litmus has just hooked into the smp_send_reschedule() IPI
handler and marked tasks as having to reschedule to implement remote
preemptions. This was never particularly clean, but so far we got away
with it. However, changes in the underlying Linux, and peculartities
of the ARM code (interrupts enabled before context switch) break this
naive approach. This patch introduces new state-machine based remote
preemption support. By examining the local state before calling
set_tsk_need_resched(), we avoid confusing the underlying Linux
scheduler. Further, this patch avoids sending unncessary IPIs.
hook litmus tick function into hrtimer-driven ticks 2010-11-11T22:57:43+00:00 Bjoern B. Brandenburg bbb@cs.unc.edu 2010-11-09T01:21:35+00:00 516b6601bb5f71035e8859735a25dea0da4a0211 Litmus plugins should also be activated if ticks are triggered by hrtimer. 
Litmus plugins should also be activated if ticks are triggered by
hrtimer.
Merge commit 'v2.6.36' into wip-merge-2.6.36 2010-10-23T05:01:49+00:00 Andrea Bastoni bastoni@cs.unc.edu 2010-10-23T05:01:49+00:00 3dd41424090a0ca3a660218d06afe6ff4441bad3 Conflicts: Makefile arch/x86/include/asm/unistd_32.h arch/x86/kernel/syscall_table_32.S kernel/sched.c kernel/time/tick-sched.c Relevant API and functions changes (solved in this commit): - (API) .enqueue_task() (enqueue_task_litmus), dequeue_task() (dequeue_task_litmus), [litmus/sched_litmus.c] - (API) .select_task_rq() (select_task_rq_litmus) [litmus/sched_litmus.c] - (API) sysrq_dump_trace_buffer() and sysrq_handle_kill_rt_tasks() [litmus/sched_trace.c] - struct kfifo internal buffer name changed (buffer -> buf) [litmus/sched_trace.c] - add_wait_queue_exclusive_locked -> __add_wait_queue_tail_exclusive [litmus/fmlp.c] - syscall numbers for both x86_32 and x86_64 
Conflicts:
	Makefile
	arch/x86/include/asm/unistd_32.h
	arch/x86/kernel/syscall_table_32.S
	kernel/sched.c
	kernel/time/tick-sched.c

Relevant API and functions changes (solved in this commit):
- (API) .enqueue_task() (enqueue_task_litmus),
  dequeue_task() (dequeue_task_litmus),
  [litmus/sched_litmus.c]
- (API) .select_task_rq() (select_task_rq_litmus)
  [litmus/sched_litmus.c]
- (API) sysrq_dump_trace_buffer() and sysrq_handle_kill_rt_tasks()
  [litmus/sched_trace.c]
- struct kfifo internal buffer name changed (buffer -> buf)
  [litmus/sched_trace.c]
- add_wait_queue_exclusive_locked -> __add_wait_queue_tail_exclusive
  [litmus/fmlp.c]
- syscall numbers for both x86_32 and x86_64
hrtimer: add init function to properly set hrtimer_start_on_info params 2010-10-19T13:40:38+00:00 Andrea Bastoni bastoni@cs.unc.edu 2010-09-28T15:08:17+00:00 bd6d5f1dd586a27c2082ad4d95ee58913b471f5c This helper function is also useful to remind us that if we use hrtimer_pull outside the scope of triggering remote releases, we need to take care of properly set the "state" field of hrtimer_start_on_info structure. 
This helper function is also useful to remind us that if we use
hrtimer_pull outside the scope of triggering remote releases, we need to
take care of properly set the "state" field of hrtimer_start_on_info
structure.
sysctl: min/max bounds are optional 2010-10-15T21:42:24+00:00 Eric Dumazet eric.dumazet@gmail.com 2010-10-15T21:34:12+00:00 a9febbb4bd1302b6f01aa1203b0a804e4e5c9e25 sysctl check complains with a WARN() when proc_doulongvec_minmax() or proc_doulongvec_ms_jiffies_minmax() are used by a vector of longs (with more than one element), with no min or max value specified. This is unexpected, given we had a bug on this min/max handling :) Reported-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: David Miller <davem@davemloft.net> Acked-by: WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
sysctl check complains with a WARN() when proc_doulongvec_minmax() or
proc_doulongvec_ms_jiffies_minmax() are used by a vector of longs (with
more than one element), with no min or max value specified.

This is unexpected, given we had a bug on this min/max handling :)

Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: David Miller <davem@davemloft.net>
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>