lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 4 Jan 2017 15:02:23 -0500
From:   Waiman Long <>
To:     Steven Rostedt <>
Cc:     Peter Zijlstra <>,
        Ingo Molnar <>,
        Thomas Gleixner <>,
        "H. Peter Anvin" <>,
Subject: Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks

On 01/04/2017 10:55 AM, Steven Rostedt wrote:
> On Wed, 4 Jan 2017 10:25:14 -0500
> Waiman Long <> 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.


Powered by blists - more mailing lists