ChangeSet 1.1832.6.22 (2004/08/24 11:10:51 [EMAIL PROTECTED]) introduced the following time slice mapping for nice values:
[ -20 ... 0 ... 19 ] => [800ms ... 100ms ... 5ms] This met the goal of a 1:160 ratio for nice-20/nice+19, however it introduced a 320ms gap between 0 and -1. Was this gap intentional or accidental, and is it really acceptable? Here's the full mapping (verified by sched_rr_get_interval): -20 => 800ms -19 => 780ms -18 => 760ms -17 => 740ms -16 => 720ms -15 => 700ms -14 => 680ms -13 => 660ms -12 => 640ms -11 => 620ms -10 => 600ms -9 => 580ms -8 => 560ms -7 => 540ms -6 => 520ms -5 => 500ms -4 => 480ms -3 => 460ms -2 => 440ms -1 => 420ms *** gap *** 0 => 100ms 1 => 95ms 2 => 90ms 3 => 85ms 4 => 80ms 5 => 75ms 6 => 70ms 7 => 65ms 8 => 60ms 9 => 55ms 10 => 50ms 11 => 45ms 12 => 40ms 13 => 35ms 14 => 30ms 15 => 25ms 16 => 20ms 17 => 15ms 18 => 10ms 19 => 5ms Take care, Jason -- [EMAIL PROTECTED] http://www.ccur.com/oss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
