From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932270AbbEHN1J (ORCPT ); Fri, 8 May 2015 09:27:09 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:37791 "EHLO mail-wi0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932149AbbEHN1F (ORCPT ); Fri, 8 May 2015 09:27:05 -0400 Date: Fri, 8 May 2015 15:27:00 +0200 From: Ingo Molnar To: Andy Lutomirski Cc: fweisbec@redhat.com, Paolo Bonzini , Thomas Gleixner , X86 ML , Peter Zijlstra , Ingo Molnar , Heiko Carstens , Mike Galbraith , "linux-kernel@vger.kernel.org" , Rik van Riel , williams@redhat.com Subject: Re: [PATCH 3/3] context_tracking,x86: remove extraneous irq disable & enable from context tracking on syscall entry Message-ID: <20150508132700.GA32628@gmail.com> References: <20150507104845.GB14924@gmail.com> <20150507124437.GB17443@gmail.com> <20150507150845.GA20608@gmail.com> <20150508063711.GA4934@gmail.com> <20150508112711.GA20444@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andy Lutomirski wrote: > > on return from idle we'd do: > > > > rcu_qs_ctr += 4-2+1; /* Register QS, clear bit 1, set bit 0 */ > > > > etc. On all boundary transitions we can use a constant ADD on a > > suitable percpu variable. > > Sounds good to me, except that we need to be careful to distinguish > between non-syscall entries from quiescent states > and non-syscall entries from quiescent states. It might be hard to make that distinction! ;-) I suspect you wanted to raise the issue of various contexts nesting on each other, such as syscall triggering a page fault, which gets an irq nested, etc. - versus non-nested contexts such as user-space triggering a page fault or user-space getting an irq? > [...] We could save the old state (as the current exception_enter > code does) or we could allocate enough low bits for the state that > the problem goes away. So I think, if it all works in practice just as well as it does in email, we might be better off with more state bits: that would tell any remote statistics/sampling code more as well. It might also be easier to patch in/out, because this kind of state tracking will affect non-RT CPUs as well. (Later on we could do a separate IDT for RT CPUs as well, with a patched version of the entry code.) > I don't think the TIF_RCU_QS variant is worthwhile -- merging the > counter and state is probably both easier and faster. Yeah. Thanks, Ingo