On 01/18/2013 09:15 PM, Oleg Nesterov wrote: > On 01/17, Preeti U Murthy wrote: >> >> On 01/16/2013 05:32 PM, Ivo Sieben wrote: >>> >>> I don't have a problem that there is a context switch to the high >>> priority process: it has a higher priority, so it probably is more >>> important. >>> My problem is that even when the waitqueue is empty, the high priority >>> thread has a risk to block on the spinlock needlessly (causing context >>> switches to low priority task and back to the high priority task) >>> >> Fair enough Ivo.I think you should go ahead with merging the >> waitqueue_active() >> wake_up() >> logic into the wake_up() variants. > > This is not easy. We can't simply change wake_up*() helpers or modify > __wake_up(). Hmm.I need to confess that I don't really know what goes into a change such as this.Since there are a lot of waitqueue_active()+wake_up() calls,I was wondering why at all have a separate logic as waitqueue_active(),if we could do what it does in wake_up*(). But you guys can decide this best. > > I can't understand why do you dislike Ivo's simple patch. There are > a lot of "if (waitqueue_active) wake_up" examples. Even if we add the > new helpers (personally I don't think this makes sense) , we can do > this later. Why should we delay this fix? Personally i was concerned about how this could cause a scheduler overhead.There does not seem to be much of a problem here.Ivo's patch for adding a waitqueue_active() for his specific problem would also do well,unless there is a dire requirement for a clean up,which I am unable to evaluate. > > Oleg. > Thank you Regards Preeti U Murthy -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
