Raistlin wrote: > Very basically: from the analysis point of view one easy and effective > solution would be to have the blocked-running tasks --i.e., the tasks > blocked on some lock that have been left on the rq to proxy-execute the > lock owner-- busy waiting while the lock owner is running. This allows > for retaining a lot of nice properties BWI already has, as far as > analyzability is concerned. > > On the other hand, from the practical end efficiency point of view, it > would be not that difficult to block these otherwise-spinning tasks, in > order to avoid wasting CPU time too much... The only important thing is > to properly account the budget of the correct server/group (which > probably must be the otherwise-spinning task's one), or the analysis is > gone again! :-O Could you elaborate on this "proper accounting"? If task A is blocked waiting for a lock (held by a task B on another cpu) and we run task C instead, how would you propose that the accounting be handled? Chris -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
