On Tue, Sep 13, 2016 at 12:32 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > On Mon, Sep 12, 2016 at 08:44:09PM -0700, Arve Hjønnevåg wrote: > >> A previous attempt to fix this problem, changed the lock to use >> rt_mutex instead of mutex, but this apparently did not work as well as >> this patch. I believe the added overhead was noticeable, and it did >> not work when the preempted thread was in a different cgroup (I don't >> know if this is still the case). > > Do you actually have RR/FIFO/DL tasks? Currently PI isn't > defined/implemented for OTHER. > Most of the tasks here are not RR/FIFO/DL tasks. I don't see anything in the rtmutex code or documentation that indicates that they don't work for normal tasks. From what I can tell the priority gets boosted in every case. This may not work as well for CFS tasks as for realtime tasks, but it should at least help when there is a large priority difference. > cgroups should be irrelevant, PI is unaware of them. I don't think cgroups are irrelevant. PI being unaware of them explains the problem I described. If the task that holds the lock is in a cgroup that has a low cpu.shares value, then boosting the task's priority within that group does necessarily make it any more likely to run. -- Arve Hjønnevåg _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
