On 01/04/2017 10:55 AM, Steven Rostedt wrote: > On Wed, 4 Jan 2017 10:25:14 -0500 > Waiman Long <long...@redhat.com> wrote: > > >> I know that in -RT kernel, all the non-raw spinlocks are replaced by >> rtmutex which is a sleeping lock. This can have a real performance >> impact on systems with more than a few cores. The rtmutex isn't fair either. > We do fine on 80+ CPUs. Is that enough cores for you ;-)
It depends on what you mean fine. I haven't done the actual benchmark yet, but I believe that a -RT system with 80+ CPUs will feel noticeably slower for non-RT tasks than a system with non-RT kernel. I am not saying that the system will slow down significantly, but the slow down will certainly be noticeable. > Note, it's not a true sleeping lock, because of the adaptive nature. > That is, it spins unless the owner of the lock is sleeping, in which > case, it too will sleep (why spin waiting for a task that isn't > running). But if the owner is running, it will spin too. I think this is a recent change by Davidlohr. However, the spinning is limited to the top waiter. The rests will still go to sleep. > We also have tricks to keep normal preemption (like SCHED_OTHER tasks > running out of their time slot) when they have a lock. This keeps > contention down on tasks owning locks while sleeping. Yes, that certainly help. >> Do you think it is better to keep the raw spinlocks fair and only have >> the non-raw spinlocks use the RT version? > Yes. OK, I can certainly do that. > > Note, I also want to get rt_mutex into the kernel first for all sleeping > locks. That is, get the logic in before we convert spin_locks to > sleeping locks. > > -- Steve The rtmutex code is already in the upstream kernel. It is just that there isn't any code yet that can let you flip a switch (a config option) and change all sleeping locks to use rtmutex. Cheers, Longman
