From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763580AbdAET1T convert rfc822-to-8bit (ORCPT ); Thu, 5 Jan 2017 14:27:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36382 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762844AbdAETZk (ORCPT ); Thu, 5 Jan 2017 14:25:40 -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> <20170105094439.GD3093@worktop> <342e0af6-43b1-76ea-0f0b-55087dfec96c@redhat.com> <20170105160834.GB3107@twins.programming.kicks-ass.net> <82624801-740f-9088-f6fb-7812f10fa146@redhat.com> <20170105135020.40187dfa@gandalf.local.home> Cc: Peter Zijlstra , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , linux-kernel@vger.kernel.org, Daniel Bristot de Oliveira From: Waiman Long Organization: Red Hat Message-ID: Date: Thu, 5 Jan 2017 14:24:36 -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: <20170105135020.40187dfa@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.27]); Thu, 05 Jan 2017 19:24:38 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/05/2017 01:50 PM, Steven Rostedt wrote: > On Thu, 5 Jan 2017 12:07:21 -0500 > Waiman Long wrote: > > >> I do make the assumption that spinlock critical sections are behaving >> well enough. Apparently, that is not a valid assumption. I sent these >> RFC patches out to see if it was an idea worth pursuing. If not, I can >> drop these patches. Anyway, thanks for the feedback. > Yes, the assumption is incorrect. There are places that can hold a spin > lock for several hundreds of microseconds. If you can't preempt them, > you'll never get below several hundreds of microseconds in latency. > > And it would be hard to pick and choose (we already do this to decide > what can be a raw_spin_lock), because you need to audit all use cases > of a spin_lock as well as all the locks taken while holding that > spin_lock. > > -- Steve Thank for the information. It has come to my attention that scalability problem may be present in the -RT kernel because of the longer wait time in the raw_spin_lock side as the number of CPUs increases. I will look into this some more to see if my patch set can help under those circumstances. Cheers, Longman