On 08/04/2014 04:48 PM, Peter Zijlstra wrote:
On Mon, Aug 04, 2014 at 02:36:35PM -0400, Waiman Long wrote:
On 08/04/2014 03:55 AM, Peter Zijlstra wrote:
On Sun, Aug 03, 2014 at 10:36:16PM -0400, Waiman Long wrote:
For a fully preemptive kernel, a call to preempt_enable() could
potentially trigger a task rescheduling event. In the case of rwsem
optimistic spinning, the task has either gotten the lock or is going
to sleep soon. So there is no point to do rescheduling here.
Uh what? Why shouldn't we preempt if we've gotten the lock? What if a
FIFO task just woke up?
I didn't mean that we shouldn't preempt if there is a higher priority task.
I am sure that there will be other preemption points along the way that a
higher priority task can take over the CPU. I just want to say that doing it
here may not be the best place especially if the task is going to sleep
soon.
If you think this patch does not make sense, I can remove it as other
patches in the set has no dependency on this one.
Yeah, its actively harmful, you delay preemption by an unspecified
amount of time in case of the spin-acquire. We've had such bugs in -rt
and they're not fun.
Basically the only time you should use no_resched is if the very next
statement is schedule().
Thank for the clarification. I will remove patch 1 from the patch set.
-Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
