Messages in this thread | | | Subject | Re: [PATCH] spin_unlock*_no_resched() | From | Steven Rostedt <> | Date | Wed, 12 Jun 2013 09:07:23 -0400 |
| |
On Wed, 2013-06-12 at 14:15 +0200, Peter Zijlstra wrote:
> So I absolutely hate this API because people can (and invariably will) > abuse it; much like they did/do preempt_enable_no_resched().
Me too.
> > IIRC Thomas even maps preempt_enable_no_resched() to preempt_enable() in > -rt to make sure we don't miss preemption points due to stupidity. > > He converted the 'few' sane sites to use schedule_preempt_disabled(). In > that vein, does it make sense to introduce schedule_spin_locked()? >
I was thinking the exact same thing when I read this patch. This is a strict policy that we should enforce and not let individual developers implement. Yes, a schedule_spin_unlock() would work nicely. The API will enforce the two to be used together. Otherwise, I can envision seeing things like:
preempt_disable(); [...]
spin_lock(x);
spin_unlock_no_resched(x);
[...]
preempt_enable();
And developers having no idea why the above is broken. Although, I would say the above is broken for other reasons, but I was just using that to show the craziness such an API would give to us.
-- Steve
| |