> It furiously looks like an off by one error (or an < versus <=
> comparison, or a postfix versus prefix increment or decrement)
> which would give actually 2 and 21 slices rather than 1 and 20:
>
> 2/23 ~= 8.7 %
> 21/23 ~= 91.3 %
yes, the reason is that we do not reschedule when we reach
current->counter == 0, but only when current->counter <= 0:
p->counter -= ticks;
if (p->counter < 0) {
p->counter = 0;
p->need_resched = 1;
this is not a problem i think, according comments should be updated:
--- linux/kernel/sched.c.orig3 Fri Jan 15 15:45:40 1999
+++ linux/kernel/sched.c Fri Jan 15 15:46:12 1999
@@ -1551,7 +1551,7 @@
* do a "normalization" of the priority (traditionally
* Unix nice values are -20 to 20; Linux doesn't really
* use that kind of thing, but uses the length of the
- * timeslice instead (default 150 ms). The rounding is
+ * timeslice instead (default 210 ms). The rounding is
* why we want to avoid negative values.
*/
newprio = (newprio * DEF_PRIORITY + 10) / 20;
--- linux/include/linux/sched.h.orig3 Fri Jan 15 15:44:59 1999
+++ linux/include/linux/sched.h Fri Jan 15 15:45:16 1999
@@ -332,7 +332,7 @@
*/
#define _STK_LIM (8*1024*1024)
-#define DEF_PRIORITY (20*HZ/100) /* 200 ms time slices */
+#define DEF_PRIORITY (20*HZ/100) /* 210 ms time slices */
/*
* INIT_TASK is used to set up the first task table, touch at
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/