> (I didn't get this done before pre9 so I waited till now!)
Which is a good thing since we want the pre-patches to
be tested in their original version by as many people
as possible...
> This is a collection of two types of fix: (a) drivers doing
> "current->counter =0;schedule()" with TASK_INTERRUPTIBLE set; (b)
> lots of architectures doing "if (current->counter <0)" when they
> should really have tested for "<= 0".
The < --> <= change should not cost anything on most
architectures and reduces the pressure a nice +19 task
puts on the system. It should go in immediately.
The current->counter = 0; trick is not needed anymore.
We've had SCHED_YIELD for ages and we're doing a timeout
anyway... Another candidate for inclusion.
> There are still loads of places (mostly in the fs code) where we
> do "current->counter =0;schedule()", but I don't know of any
> better way to do the waits in those cases. Perhaps they are
> conceptually optimal anyway.
Probably not. Artificially setting current->counter to 0
is very unfair and can be bad for the system's interactive
feel. We should use SCHED_YIELD in this case.
Rik -- If a Microsoft product fails, who do you sue?
+-------------------------------------------------------------------+
| Linux memory management tour guide. riel@nl.linux.org |
| Scouting Vries cubscout leader. http://www.nl.linux.org/~riel |
+-------------------------------------------------------------------+
-
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/