title: sched_wakeup_granularity_ns , sched_min_granularity_ns and SCHED_RR
body: <p>The following value from my box :</p>
  
  <pre><code>sysctl -A | grep "sched" | grep -v "domain"
  
  kernel.sched_autogroup_enabled = 0
  kernel.sched_cfs_bandwidth_slice_us = 5000
  kernel.sched_child_runs_first = 0
  kernel.sched_latency_ns = 18000000
  kernel.sched_migration_cost_ns = 5000000
  kernel.sched_min_granularity_ns = 10000000
  kernel.sched_nr_migrate = 32
  kernel.sched_rr_timeslice_ms = 100
  kernel.sched_rt_period_us = 1000000
  kernel.sched_rt_runtime_us = 950000
  kernel.sched_shares_window_ns = 10000000
  kernel.sched_time_avg_ms = 1000
  kernel.sched_tunable_scaling = 1
  kernel.sched_wakeup_granularity_ns = 3000000
  </code></pre>
  
  <p>It means in one second , 0.95 second is for SCHED_FIFO or SCHED_RR ,
  only 0.05  reserved for SCHED_OTHER  ,  What  I  am curious is<br>
  sched_wakeup_granularity_ns   ,   I have googled it and get the explanation :</p>
  
  <pre><code>Ability of tasks being woken to preempt the current task. 
  The smaller the value, the easier it is for the task to force the preemption
  </code></pre>
  
  <p>I think sched_wakeup_granularity_ns  only effect SCHED_OTHER task , 
  the SCHED_FIFO and SCHED_RR should not in sleep mode , so no need to "wakeup",
  am I correct ?!</p>
  
  <p>and   for  sched_min_granularity_ns, the explanation is :</p>
  
  <pre><code>Minimum preemption granularity for processor-bound tasks. 
  Tasks are guaranteed to run for this minimum time before they are preempted
  </code></pre>
  
  <p>I like to know , although SCHED_RR tasks can has 95% of cpu time , But
  since the sched_min_granularity_ns value = 10000000 , it is 0.01  second ,
  that means that every SCHED_OTHER get 0.01 second timeslice to run before been preempted unless it is blocked by blocking socket or sleep or else , it imply that if I have 3 tasks in core 1 for example , 2 tasks with SCHED_RR , the third task with SCHED_OTHER , and the third task just run a endless loop without blocking socket recv  and without yield , so once the third task get the cpu and run , it will run 0.01 second
  and then context switch out , even the next task is priority with SCHED_RR ,
  it is the right understaning for sched_min_granularity_ns usage ?!</p>
  
  <p>Edit :</p>
  
  <p><a href="http://lists.pdxlinux.org/pipermail/plug/2006-February/045495.html" rel="nofollow">http://lists.pdxlinux.org/pipermail/plug/2006-February/045495.html</a></p>
  
  <p>describe :</p>
  
  <pre><code>No SCHED_OTHER process may be preempted by another SCHED_OTHER process.
  However a SCHED_RR or SCHED_FIFO process will preempt SCHED_OTHER
  process before their time slice is done. So a SCHED_RR process
  should wake up from a sleep with fairly good accuracy.
  </code></pre>
  
  <p>means SCHED_RR task can preempt the endless while loop without blocking even
  time slice is not done ?!</p>