From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936903AbdADUCk convert rfc822-to-8bit (ORCPT ); Wed, 4 Jan 2017 15:02:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39422 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936882AbdADUCZ (ORCPT ); Wed, 4 Jan 2017 15:02:25 -0500 Subject: Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks To: Steven Rostedt References: <1483466430-8028-1-git-send-email-longman@redhat.com> <20170104124929.GI25813@worktop.programming.kicks-ass.net> <57c0a6e1-1fab-b8d4-2a68-02cc1ebf7ce6@redhat.com> <20170104105518.680460cf@gandalf.local.home> Cc: Peter Zijlstra , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , linux-kernel@vger.kernel.org From: Waiman Long Organization: Red Hat Message-ID: <7f3195a3-6ae2-38c8-80af-e38f670e83fd@redhat.com> Date: Wed, 4 Jan 2017 15:02:23 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170104105518.680460cf@gandalf.local.home> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 04 Jan 2017 20:02:25 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Cheers, Longman