Messages in this thread | | | Subject | Re: [patch] sched: fix scheduling latencies for !PREEMPT kernels | From | Robert Love <> | Date | Tue, 14 Sep 2004 15:26:42 -0400 |
| |
On Tue, 2004-09-14 at 12:21 -0700, William Lee Irwin III wrote:
> Far from "just throw away" -- this is hard work! Very hard work, and a > number of people have already tried and failed.
That is my point.
> The "safely call schedule() while holding it" needs quite a bit of > qualification; it's implicitly dropped during voluntary context > switches and reacquired when rescheduled, but it's not valid to force > such a task into an involuntary context switch and calling schedule() > implies dropping the lock, so it has to be done at the proper times. > This is a complex semantic that likely trips up numerous callers (as > well as attempts to explain it, though surely you know these things, > and merely wanted a shorter line for the bullet point).
Right. I meant safe against deadlocks. It obviously is not "safe" to reschedule in the middle of your critical region.
> I'd actually like to go the opposite direction from Ingo: I'd like to > remove uses of the sleeping characteristic first, as in my mind that is > the most pernicious and causes the most subtleties. Afterward, the > recursion. Except it's unclear that I have the time/etc. resources to > address it apart from taking on small pieces of whatever auditing work > or sweeps others care to devolve to me, so I'll largely be using > whatever tactic whoever cares to drive all this (probably Alan) prefers.
This, too, is exactly what I am saying.
I want to remove the sleep characteristic.
One way to do that is start special casing it. Document it with the code, e.g. make an explicit cond_resched_bkl().
Robert Love
- 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/
| |