---

yaml
---
r: 145799
b: refs/heads/master
c: 0e2595c
h: refs/heads/master
i:
  145797: 6ceed1d
  145795: 1adb137
  145791: 6675e3a
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: bec706838ec2f9c8c2b99e88a1270d7cba159b06
+refs/heads/master: 0e2595cdfd7df9f1128f7185152601ae5417483b

trunk/Documentation/kernel-parameters.txt

@@ -1575,9 +1575,6 @@ and is between 256 and 4096 characters. It is defined in the file
 	noinitrd	[RAM] Tells the kernel not to load any configured
 			initial RAM disk.
 
-	nointremap	[X86-64, Intel-IOMMU] Do not enable interrupt
-			remapping.
-
 	nointroute	[IA-64]
 
 	nojitter	[IA64] Disables jitter checking for ITC timers.

trunk/Documentation/memory-barriers.txt

@@ -31,7 +31,6 @@ Contents:
 
      - Locking functions.
      - Interrupt disabling functions.
-     - Sleep and wake-up functions.
      - Miscellaneous functions.
 
  (*) Inter-CPU locking barrier effects.
@@ -1218,132 +1217,6 @@ barriers are required in such a situation, they must be provided from some
 other means.
 
 
-SLEEP AND WAKE-UP FUNCTIONS
----------------------------
-
-Sleeping and waking on an event flagged in global data can be viewed as an
-interaction between two pieces of data: the task state of the task waiting for
-the event and the global data used to indicate the event.  To make sure that
-these appear to happen in the right order, the primitives to begin the process
-of going to sleep, and the primitives to initiate a wake up imply certain
-barriers.
-
-Firstly, the sleeper normally follows something like this sequence of events:
-
-	for (;;) {
-		set_current_state(TASK_UNINTERRUPTIBLE);
-		if (event_indicated)
-			break;
-		schedule();
-	}
-
-A general memory barrier is interpolated automatically by set_current_state()
-after it has altered the task state:
-
-	CPU 1
-	===============================
-	set_current_state();
-	  set_mb();
-	    STORE current->state
-	    <general barrier>
-	LOAD event_indicated
-
-set_current_state() may be wrapped by:
-
-	prepare_to_wait();
-	prepare_to_wait_exclusive();
-
-which therefore also imply a general memory barrier after setting the state.
-The whole sequence above is available in various canned forms, all of which
-interpolate the memory barrier in the right place:
-
-	wait_event();
-	wait_event_interruptible();
-	wait_event_interruptible_exclusive();
-	wait_event_interruptible_timeout();
-	wait_event_killable();
-	wait_event_timeout();
-	wait_on_bit();
-	wait_on_bit_lock();
-
-
-Secondly, code that performs a wake up normally follows something like this:
-
-	event_indicated = 1;
-	wake_up(&event_wait_queue);
-
-or:
-
-	event_indicated = 1;
-	wake_up_process(event_daemon);
-
-A write memory barrier is implied by wake_up() and co. if and only if they wake
-something up.  The barrier occurs before the task state is cleared, and so sits
-between the STORE to indicate the event and the STORE to set TASK_RUNNING:
-
-	CPU 1				CPU 2
-	===============================	===============================
-	set_current_state();		STORE event_indicated
-	  set_mb();			wake_up();
-	    STORE current->state	  <write barrier>
-	    <general barrier>		  STORE current->state
-	LOAD event_indicated
-
-The available waker functions include:
-
-	complete();
-	wake_up();
-	wake_up_all();
-	wake_up_bit();
-	wake_up_interruptible();
-	wake_up_interruptible_all();
-	wake_up_interruptible_nr();
-	wake_up_interruptible_poll();
-	wake_up_interruptible_sync();
-	wake_up_interruptible_sync_poll();
-	wake_up_locked();
-	wake_up_locked_poll();
-	wake_up_nr();
-	wake_up_poll();
-	wake_up_process();
-
-
-[!] Note that the memory barriers implied by the sleeper and the waker do _not_
-order multiple stores before the wake-up with respect to loads of those stored
-values after the sleeper has called set_current_state().  For instance, if the
-sleeper does:
-
-	set_current_state(TASK_INTERRUPTIBLE);
-	if (event_indicated)
-		break;
-	__set_current_state(TASK_RUNNING);
-	do_something(my_data);
-
-and the waker does:
-
-	my_data = value;
-	event_indicated = 1;
-	wake_up(&event_wait_queue);
-
-there's no guarantee that the change to event_indicated will be perceived by
-the sleeper as coming after the change to my_data.  In such a circumstance, the
-code on both sides must interpolate its own memory barriers between the
-separate data accesses.  Thus the above sleeper ought to do:
-
-	set_current_state(TASK_INTERRUPTIBLE);
-	if (event_indicated) {
-		smp_rmb();
-		do_something(my_data);
-	}
-
-and the waker should do:
-
-	my_data = value;
-	smp_wmb();
-	event_indicated = 1;
-	wake_up(&event_wait_queue);
-
-
 MISCELLANEOUS FUNCTIONS
 -----------------------
 
@@ -1493,7 +1366,7 @@ WHERE ARE MEMORY BARRIERS NEEDED?
 
 Under normal operation, memory operation reordering is generally not going to
 be a problem as a single-threaded linear piece of code will still appear to
-work correctly, even if it's in an SMP kernel.  There are, however, four
+work correctly, even if it's in an SMP kernel.  There are, however, three
 circumstances in which reordering definitely _could_ be a problem:
 
  (*) Interprocessor interaction.

trunk/Documentation/scheduler/sched-rt-group.txt

@@ -4,7 +4,6 @@
 CONTENTS
 ========
 
-0. WARNING
 1. Overview
   1.1 The problem
   1.2 The solution
@@ -15,23 +14,6 @@ CONTENTS
 3. Future plans
 
 
-0. WARNING
-==========
-
- Fiddling with these settings can result in an unstable system, the knobs are
- root only and assumes root knows what he is doing.
-
-Most notable:
-
- * very small values in sched_rt_period_us can result in an unstable
-   system when the period is smaller than either the available hrtimer
-   resolution, or the time it takes to handle the budget refresh itself.
-
- * very small values in sched_rt_runtime_us can result in an unstable
-   system when the runtime is so small the system has difficulty making
-   forward progress (NOTE: the migration thread and kstopmachine both
-   are real-time processes).
-
 1. Overview
 ===========
 
@@ -187,7 +169,7 @@ get their allocated time.
 
 Implementing SCHED_EDF might take a while to complete. Priority Inheritance is
 the biggest challenge as the current linux PI infrastructure is geared towards
-the limited static priority levels 0-99. With deadline scheduling you need to
+the limited static priority levels 0-139. With deadline scheduling you need to
 do deadline inheritance (since priority is inversely proportional to the
 deadline delta (deadline - now).
 

trunk/Documentation/trace/ftrace.txt

@@ -518,18 +518,9 @@ priority with zero (0) being the highest priority and the nice
 values starting at 100 (nice -20). Below is a quick chart to map
 the kernel priority to user land priorities.
 
-   Kernel Space                     User Space
- ===============================================================
-   0(high) to  98(low)     user RT priority 99(high) to 1(low)
-                           with SCHED_RR or SCHED_FIFO
- ---------------------------------------------------------------
-  99                       sched_priority is not used in scheduling
-                           decisions(it must be specified as 0)
- ---------------------------------------------------------------
- 100(high) to 139(low)     user nice -20(high) to 19(low)
- ---------------------------------------------------------------
- 140                       idle task priority
- ---------------------------------------------------------------
+  Kernel priority: 0 to 99    ==> user RT priority 99 to 0
+  Kernel priority: 100 to 139 ==> user nice -20 to 19
+  Kernel priority: 140        ==> idle task priority
 
 The task states are: