Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751952AbbEAQ06 (ORCPT ); Fri, 1 May 2015 12:26:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59481 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751183AbbEAQ05 (ORCPT ); Fri, 1 May 2015 12:26:57 -0400 Message-ID: <5543A94B.3020108@redhat.com> Date: Fri, 01 May 2015 12:26:51 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ingo Molnar , Andy Lutomirski CC: "linux-kernel@vger.kernel.org" , X86 ML , williams@redhat.com, Andrew Lutomirski , fweisbec@redhat.com, Peter Zijlstra , Heiko Carstens , Thomas Gleixner , Ingo Molnar , Paolo Bonzini Subject: Re: [PATCH 3/3] context_tracking,x86: remove extraneous irq disable & enable from context tracking on syscall entry References: <1430429035-25563-1-git-send-email-riel@redhat.com> <1430429035-25563-4-git-send-email-riel@redhat.com> <20150501064044.GA18957@gmail.com> <554399D1.6010405@redhat.com> <20150501155912.GA451@gmail.com> <20150501162109.GA1091@gmail.com> In-Reply-To: <20150501162109.GA1091@gmail.com> 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 Content-Length: 2158 Lines: 58 On 05/01/2015 12:21 PM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >>> So what's the point? Why not remove this big source of overhead >>> altogether? >> >> The last time I asked, the impression I got was that we needed two >> things: >> >> 1. We can't pluck things from the RCU list without knowing whether >> the CPU is in an RCU read-side critical section, and we can't know >> that unless we have regular grade periods or we know that the CPU is >> idle. To make the CPU detectably idle, we need to set a bit >> somewhere. > > 'Idle' as in 'executing pure user-space mode, without entering the > kernel and possibly doing an rcu_read_lock()', right? > > So we don't have to test it from the remote CPU: we could probe such > CPUs via a single low-overhead IPI. I'd much rather push such overhead > to sync_rcu() than to the syscall entry code! > > I can understand people running hard-RT workloads not wanting to see > the overhead of a timer tick or a scheduler tick with variable (and > occasionally heavy) work done in IRQ context, but the jitter caused by > a single trivial IPI with constant work should be very, very low and > constant. Not if the realtime workload is running inside a KVM guest. At that point an IPI, either on the host or in the guest, involves a full VMEXIT & VMENTER cycle. I suspect it would be easy enough at user_enter() or guest_enter() time to: 1) flip the bit 2) check to see if we have any callbacks queued on our on queue, and 3) if so, move the callbacks from that queue to the "another CPU can take these" queue At that point, another CPU wanting to do an RCU grace period advance can: 1) skip trying to advance the grace period on the CPU that is in userspace or guest mode, and 2) take the "for somebody else" callbacks of that CPU, and run them This does not seem overly complicated. -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/