From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763010AbdAERH4 convert rfc822-to-8bit (ORCPT ); Thu, 5 Jan 2017 12:07:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33266 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1763016AbdAERHq (ORCPT ); Thu, 5 Jan 2017 12:07:46 -0500 Subject: Re: [RFC PATCH 0/7] locking/rtqspinlock: Realtime queued spinlocks To: Peter Zijlstra 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> Cc: Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , linux-kernel@vger.kernel.org, Steven Rostedt , Daniel Bristot de Oliveira From: Waiman Long Organization: Red Hat Message-ID: <82624801-740f-9088-f6fb-7812f10fa146@redhat.com> Date: Thu, 5 Jan 2017 12:07:21 -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: <20170105160834.GB3107@twins.programming.kicks-ass.net> 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.39]); Thu, 05 Jan 2017 17:07:22 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/05/2017 11:08 AM, Peter Zijlstra wrote: > On Thu, Jan 05, 2017 at 10:55:55AM -0500, Waiman Long wrote: >> What I am saying that we don't need to change spinlock to rtmutex in a >> -RT kernel. Instead, we can use rtqspinlock for this purpose. All the >> sleeping locks will still be converted to rtmutex. > No-no-no.. > >> Conversion of rtmutex does allow forced CPU preemption when there is a >> need for that. What rtqspinlock can provide is voluntary preemption >> where the lock waiters explicitly yield the CPU while waiting for the >> lock. I use the need_resched() to detect if CPU yielding is necessary. >> However, if the CPU was in a preempt disabled region before the >> spin_lock() call, we can't yield the CPU. The only way is to raise its >> priority and try to get the lock ASAP. > And here you've lost your finger because the saw-blade didn't stop in > time. Well, I lost my virtual fingers all the time;-) This is one way that I learn and become stronger. > RT very fundamentally relies on the spinlock->rtmutex conversion to > allow preempting things when a higher priority task comes along. A > spinlock, of any kind, requires having preemption disabled while holding > the lock. If the critical section is of unbounded latency, you have > unbounded preemption latency and RT is no more. > > Its not about PI on contention, although that helps inversion scenarios. > Its about allowing preemption, which fundamentally requires a sleeping > lock to be used. > > Many of the spinlock sections of mainline are not well behaved in an RT > sense and therefore must not disable preemption. Similar for the IRQ > disable regions and hence we have the whole threaded interrupt stuff. 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. Cheers, Longman