On 20/11/2013 18:04, Peter Zijlstra wrote: > The only valid use of preempt_enable_no_resched() is if the very next > line is schedule() or if we know preemption cannot actually be enabled > by that statement due to known more preempt_count 'refs'.
The reason I used the no resched version is that busy_poll_end_time() is almost always called with rcu read lock held, so it seemed the more correct option. I have no issue with you changing this. > As to the busy_poll mess; that looks to be completely and utterly > broken, sched_clock() can return utter garbage with interrupts enabled > (rare but still), it can drift unbounded between CPUs, so if you get > preempted/migrated and your new CPU is years behind on the previous > CPU we get to busy spin for a _very_ long time. There is a _REASON_ > sched_clock() warns about preemptability - papering over it with a > preempt_disable()/preempt_enable_no_resched() is just terminal brain > damage on so many levels. IMHO This has been reviewed thoroughly. When Ben Hutchings voiced concerns I rewrote the code to use time_after, so even if you do get switched over to a CPU where the time is random you will at most poll another full interval. Linus asked me to remove this since it makes us use two time values instead of one. see https://lkml.org/lkml/2013/7/8/345. Cheers, Eliezer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
