From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754298Ab3HLUpp (ORCPT ); Mon, 12 Aug 2013 16:45:45 -0400 Received: from terminus.zytor.com ([198.137.202.10]:53130 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750938Ab3HLUpn (ORCPT ); Mon, 12 Aug 2013 16:45:43 -0400 Message-ID: <5209494B.4050209@zytor.com> Date: Mon, 12 Aug 2013 13:44:59 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Linus Torvalds CC: Ingo Molnar , Peter Zijlstra , Thomas Gleixner , Mike Galbraith , Andi Kleen , Linux Kernel Mailing List Subject: Re: [RFC] per-cpu preempt_count References: <20130812115113.GE27162@twins.programming.kicks-ass.net> <20130812175830.GB18691@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/12/2013 12:00 PM, Linus Torvalds wrote: > > Wrong. The thing is, the common case for preempt is to increment and > decrement the count, not testing it. Exactly because we do this for > spinlocks and for rcu read-locked regions. > > Now, what we *could* do is to say: > > - we will use the high bit of the preempt count for NEED_RESCHED > > - when we set/clear that high bit, we *always* use atomic sequences, > and we never change any of the other bits. > > - we will increment/decrement the other counters, we *only* do so on > the local CPU, and we don't use atomic accesses. > > Now, the downside of that is that *because* we don't use atomic > accesses for the inc/dec parts, the updates to the high bit can get > lost. But because the high bit updates are done with atomics, we know > that they won't mess up the actual counting bits, so at least the > count is never corrupted. > > And the NEED_RESCHED bit getting lost would be very unusual. That > clearly would *not* be acceptable for RT, but it it might be > acceptable for "in the unusual case where we want to preempt a thread > that was not preemtible, *and* we ended up having the extra unsual > case that preemption enable ended up missing the preempt bit, we don't > get preempted in a timely manner". It's probably impossible to ever > see in practice, and considering that for non-RT use the PREEMPT bit > is a "strong hint" rather than anything else, it sounds like it might > be acceptable. > > It is obviously *not* going to be acceptable for the RT people, > though, but since they do different code sequences _anyway_, that's > not really much of an issue. > This seems more pain than need be if checking the count in the slow path is okay. -hpa