> > - p->counter = current->counter;
> > - current->counter = 0;
> > + p->counter = (current->counter + 1) >> 1;
> > + current->counter >>= 1;
> > + current->policy |= SCHED_YIELD;
> > current->need_resched = 1;
>
> please try to reproduce the bad behaviour with 2.4.4aa2. There's a bug
> in the parent-timeslice patch in 2.4 that I fixed while backporting it
> to 2.2aa and that I now forward ported the fix to 2.4aa. The fact
> 2.4.4 gives the whole timeslice to the child just gives more light to
> such bug.
The fact that 2.4.4 gives the whole timeslice to the child
is just bogus to begin with.
The problem people tried to solve was "make sure the kernel
runs the child first after a fork", this has just about
NOTHING to do with how the timeslice is distributed.
Now, since we are in a supposedly stable branch of the kernel,
why mess with the timeslice distribution between parent and
child? The timeslice distribution that has worked very well
for the last YEARS...
I agree when people want to fix problems, but I really don't
think 2.4 is the time to also "fix" non-problems.
regards,
Rik
-- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose...http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to aardvark@nl.linux.org (spam digging piggy)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/