[PATCH] preemptive kernel behavior change: don't be rude
- do not manually set task->state - instead, in preempt_schedule, set a flag in preempt_count that denotes that this task is entering schedule off a kernel preemption. - use this flag in schedule to jump to pick_next_task - in preempt_schedule, upon return from schedule, unset the flag - have entry.S just call preempt_schedule and not duplicate this work, as Linus suggested. I agree. Note this makes debugging easier as we keep a single point of entry for kernel preemptions. The result: we can safely preempt non-TASK_RUNNING tasks. If one is preempted, we can safely survive schedule because we won't handle the special casing of non-TASK_RUNNING at the top of schedule. Thus other tasks can run as desired and our non-TASK_RUNNING task will eventually be rescheduled, in its original state, and complete happily. This is the behavior we have in the 2.4 patches and 2.5 until ~2.5.6-pre. This works. It requires no other changes elsewhere (it actually removes some special-casing Ingo did in the signal code).
Showing
Please register or sign in to comment