![]() | |||||||||||||
Messages in this thread |
Andrea Arcangeli wrote: > >BTW, with preempt enabled there is no guarantee that RCU can ever reach >a quiescient point and secondly there is no guarantee that you will ever >be allowed to unplug a CPU hotline since again there's no guarantee to >reach a quiescient point. Think a kernel thread doing for (;;) (i.e. >math computations in background, to avoid starving RCU the kernel thread >will have to add schedule() explicitly no matter if PREEMPT=y or >PREEMPT=n, again invalidating the point of preempt, the rcu tracking for >PREEMT=y is also more expensive). > > Why is this so? schedule() runs RCU_qsctr(task_cpu(prev))++; whether it is called directly or via preempt_schedule. >Note, the work you and the other preempt developers did with preempt was >great, it wouldn't be possible to be certain that it wasn't worthwhile >until we had the thing working and finegrined (i.e. in all in_interrupt >etc..), and now we know it doesn't payoff and in turn I'm going to try >the explicit-preempt that is to explicitly enable preempt in a few >cpu-intensive kernel spots where we don't take locks (i.e. copy-user), >the original suggestion I did 4 years ago, I believe in such places an >explicit-preempt will work best since we've already to check every few >bytes the current->need_resched, so adding a branch there should be very >worthwhile. Doing real preempt like now is overkill instead and should >be avoided IMHO. > > Technically, I think preempt can still reduce maximum latency depending on whether the time between explicit resched checks is greater than the (small) scheduling overhead that preempt adds. But yeah, that would be in the noise compared with long preempt-off regions. I'm not sure about applications, but maybe some soft-realtime things like audio software benefit from a lower average latency (I don't know). - 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/ | ||||||||||||
| Last update: 2005-03-22 13:01 [from the cache] ©2003-2008 | |||||||||||||