Hi Daniel, On 07/11/16 14:51, Daniel Bristot de Oliveira wrote: > On 11/07/2016 11:31 AM, Tommaso Cucinotta wrote: [...] > > -) only issue might be that, if a non-RT task wakes up after the > > unthrottle, it will have to wait, but worst-case it will have a chance > > in the next throttling window > > In the current default behavior (RT_RUNTIME_SHARING), in a domain with > more than two CPUs, the worst case easily become "infinity," because a > CPU can borrow runtime from another CPU. There is no guarantee for > minimum latency for non-rt tasks. Anyway, if the user wants to provide > such guarantee, they just need not enable this feature, while disabling > RT_RUNTIME_SHARING (or run the non-rt task as a deadline task ;-)) > I could only skim through the patch, so please forgive me if I'm talking gibberish, but I think what Tommaso is saying is that with your current approach if an unlucky OTHER task wakes up just after you unthrottled an rt_rq (by replenishment), it will have to wait until the next throttling event. I agree that this is still better than current status, and that you can still configure the system to avoid this from happening. What I'm wondering though is if we could modify your implementation and only do the replenishment when the replenishment timer actually fires, but let RT tasks continue to run, while their rt_rq is throttled, if no OTHER task is present, or wakes up. I guess this will complicate things, and maybe doesn't buy us much, just an idea. :) Otherwise, the patch looks good and useful to me. Best, - Juri -- 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
