1 files changed, 211 insertions, 1 deletions

diff --git a/litmus/Kconfig b/litmus/Kconfig
index bd6635c8de08..594c54342bdc 100644
--- a/litmus/Kconfig
+++ b/litmus/Kconfig
@@ -34,8 +34,70 @@ config RELEASE_MASTER
            (http://www.cs.unc.edu/~anderson/papers.html).
            Currently only supported by GSN-EDF.
 
+config REALTIME_AUX_TASKS
+        bool "Real-Time Auxillary Tasks"
+        depends on LITMUS_LOCKING
+        default n
+        help
+                Adds a system call that forces all non-real-time threads in a process
+                to become auxillary real-time tasks. These tasks inherit the priority of
+                the highest-prio *BLOCKED* (but NOT blocked on a Litmus lock) real-time
+                task (non-auxillary) in the process. This allows the integration of COTS
+                code that has background helper threads used primarily for message passing
+                and synchronization. If these background threads are NOT real-time scheduled,
+                then unbounded priority inversions may occur if a real-time task blocks on
+                a non-real-time thread.
+
+                Beware of the following pitfalls:
+                  1) Auxillary threads should not be CPU intensive. They should mostly
+                     block on mutexes and condition variables. Violating this will
+                         likely prevent meaningful analysis.
+                  2) Since there may be more than one auxillary thread per process,
+                     priority inversions may occur with respect to single-threaded
+                         task models if/when one of threads are scheduled simultanously
+                         with another of the same identity.
+
+choice
+        prompt "Scheduling prioritization of AUX tasks."
+        default REALTIME_AUX_TASK_PRIORITY_BOOSTED
+        help
+                Select the prioritization method for auxillary tasks.
+
+config REALTIME_AUX_TASK_PRIORITY_BOOSTED
+        bool "Boosted"
+        help
+                Run all auxillary task threads at a maximum priority. Useful for
+                temporarily working around bugs during development.
+
+config REALTIME_AUX_TASK_PRIORITY_INHERITANCE
+        bool "Inheritance"
+        help
+                Auxillary tasks inherit the maximum priority from blocked real-time
+                threads within the same process.
+
+                Additional pitfall:
+                  3) Busy-wait deadlock is likely between normal real-time tasks and
+                     auxillary tasks synchronize using _preemptive_ spinlocks that do
+                         not use priority inheritance.
+
+                These pitfalls are mitgated by the fact that auxillary tasks only
+                inherit priorities from blocked tasks (Blocking signifies that the
+                blocked task _may_ be waiting on an auxillary task to perform some
+                work.). Futher, auxillary tasks without an inherited priority are
+                _always_ scheduled with a priority less than any normal real-time task!!
+
+                NOTE: Aux tasks do not _directly_ inherit a priority from rt tasks that
+                are blocked on Litmus locks. Aux task should be COTS code that know nothing
+                of Litmus, so they won't hold Litmus locks. Nothing the aux task can do can
+                _directly_ unblock the rt task blocked on a Litmus lock. However, the lock
+                holder that blocks the rt task CAN block on I/O and contribute its priority
+                to the aux tasks. Aux tasks may still _indirectly_ inherit the priority of
+                the blocked rt task via the lock holder.
+endchoice
+
 endmenu
 
+
 menu "Real-Time Synchronization"
 
 config NP_SECTION
@@ -60,6 +122,42 @@ config LITMUS_LOCKING
           Say Yes if you want to include locking protocols such as the FMLP and
           Baker's SRP.
 
+config LITMUS_AFFINITY_LOCKING
+        bool "Enable affinity infrastructure in k-exclusion locking protocols."
+        depends on LITMUS_LOCKING
+        default n
+        help
+          Enable affinity tracking infrastructure in k-exclusion locking protocols.
+          This only enabled the *infrastructure* not actual affinity algorithms.
+
+          If unsure, say No.
+
+config LITMUS_NESTED_LOCKING
+                bool "Support for nested inheritance in locking protocols"
+        depends on LITMUS_LOCKING
+        default n
+        help
+          Enable nested priority inheritance.
+
+config LITMUS_DGL_SUPPORT
+        bool "Support for dynamic group locks"
+        depends on LITMUS_NESTED_LOCKING
+        default n
+        help
+          Enable dynamic group lock support.
+
+config LITMUS_MAX_DGL_SIZE
+        int "Maximum size of a dynamic group lock."
+        depends on LITMUS_DGL_SUPPORT
+        range 1 128
+        default "10"
+        help
+                Dynamic group lock data structures are allocated on the process
+                stack when a group is requested. We set a maximum size of
+                locks in a dynamic group lock to avoid dynamic allocation.
+
+                TODO: Batch DGL requests exceeding LITMUS_MAX_DGL_SIZE.
+
 endmenu
 
 menu "Performance Enhancements"
@@ -112,6 +210,14 @@ choice
           Break ties between two jobs, A and B, with equal deadlines by using a
           uniform hash; i.e.: hash(A.pid, A.job_num) < hash(B.pid, B.job_num). Job
           A has ~50% of winning a given tie-break.
+
+          NOTES:
+            * This method doesn't work very well if a tied job has a low-valued
+                  hash while the jobs it ties with do not make progress (that is,
+                  they don't increment to new job numbers). The job with a low-valued
+                  hash job will lose most tie-breaks. This is usually not a problem
+                  unless you are doing something funky in Litmus (ex. worker threads
+                  that do not increment job numbers).
         
         config EDF_PID_TIE_BREAK
         bool "PID-based Tie Breaks"
@@ -167,7 +273,7 @@ config SCHED_TASK_TRACE
 config SCHED_TASK_TRACE_SHIFT
        int "Buffer size for sched_trace_xxx() events"
        depends on SCHED_TASK_TRACE
-       range 8 13
+       range 8 15
        default 9
        help
 
@@ -279,4 +385,108 @@ config PREEMPT_STATE_TRACE
 
 endmenu
 
+menu "Interrupt Handling"
+
+choice 
+        prompt "Scheduling of interrupt bottom-halves in Litmus."
+        default LITMUS_SOFTIRQD_NONE
+        depends on LITMUS_LOCKING
+        help
+                Schedule tasklets with known priorities in Litmus.
+
+config LITMUS_SOFTIRQD_NONE
+        bool "No tasklet scheduling in Litmus."
+        help
+          Don't schedule tasklets in Litmus.  Default.
+
+config LITMUS_SOFTIRQD
+        bool "Spawn klmirqd interrupt handling threads."
+        help
+          Create klmirqd interrupt handling threads.  Work must be
+          specifically dispatched to these workers.  (Softirqs for
+          Litmus tasks are not magically redirected to klmirqd.)
+
+          G-EDF, C-EDF ONLY for now!
+
+
+config LITMUS_PAI_SOFTIRQD
+        bool "Defer tasklets to context switch points."
+        help
+          Only execute scheduled tasklet bottom halves at
+          scheduling points.  Trades context switch overhead
+          at the cost of non-preemptive durations of bottom half
+          processing.
+                 
+          G-EDF, C-EDF ONLY for now!     
+                 
+endchoice          
+           
+
+config LITMUS_NVIDIA
+          bool "Litmus handling of NVIDIA interrupts."
+          default n
+          help
+            Direct tasklets from NVIDIA devices to Litmus's klmirqd
+                or PAI interrupt handling routines.
+
+                If unsure, say No.
+
+config LITMUS_AFFINITY_AWARE_GPU_ASSINGMENT
+          bool "Enable affinity-aware heuristics to improve GPU assignment."
+          depends on LITMUS_NVIDIA && LITMUS_AFFINITY_LOCKING
+          default n
+          help
+            Enable several heuristics to improve the assignment
+                of GPUs to real-time tasks to reduce the overheads
+                of memory migrations.
+
+                If unsure, say No.
+
+config NV_DEVICE_NUM
+           int "Number of NVIDIA GPUs."
+           depends on LITMUS_SOFTIRQD || LITMUS_PAI_SOFTIRQD
+           range 1 16
+           default "1"
+           help
+             Should be (<= to the number of CPUs) and
+                 (<= to the number of GPUs) in your system.
+
+choice
+          prompt "CUDA/Driver Version Support"
+          default CUDA_5_0
+          depends on LITMUS_NVIDIA
+          help
+                Select the version of CUDA/driver to support.
+
+config CUDA_5_0
+          bool "CUDA 5.0"
+          depends on LITMUS_NVIDIA && REALTIME_AUX_TASKS
+          help
+            Support CUDA 5.0 RCx (dev. driver version: x86_64-304.33)
+
+config CUDA_4_0
+          bool "CUDA 4.0"
+          depends on LITMUS_NVIDIA
+          help
+                Support CUDA 4.0 RC2 (dev. driver version: x86_64-270.40)
+
+config CUDA_3_2
+          bool "CUDA 3.2"
+          depends on LITMUS_NVIDIA
+          help
+                Support CUDA 3.2 (dev. driver version: x86_64-260.24)
+
+endchoice
+
+config LITMUS_NV_KLMIRQD_DEBUG
+          bool "Raise fake sporadic tasklets to test nv klimirqd threads."
+          depends on LITMUS_NVIDIA && LITMUS_SOFTIRQD
+          default n
+          help
+                Causes tasklets to be sporadically dispatched to waiting klmirqd
+                threads.  WARNING! Kernel panic may occur if you switch between
+                LITMUS plugins!
+
+endmenu
+
 endmenu