From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751673AbbEAQWS (ORCPT ); Fri, 1 May 2015 12:22:18 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:35730 "EHLO mail-wi0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751569AbbEAQWP (ORCPT ); Fri, 1 May 2015 12:22:15 -0400 Date: Fri, 1 May 2015 18:21:09 +0200 From: Ingo Molnar To: Andy Lutomirski Cc: Rik van Riel , "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 Message-ID: <20150501162109.GA1091@gmail.com> 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> 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: > > 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. If user-space RT code does not tolerate _that_ kind of latencies then it really has its priorities wrong and we should not try to please it. It should not hurt the other 99.9% of sane hard-RT users. And the other usecase, virtualization, obviously does not care and could take the IPI just fine. > 2. To suppress the timing tick, we need to get some timing for, um, > the scheduler? I wasn't really sure about this one. So we have variable timeslice timers for the scheduler implemented, they are off by default but they worked last someone tried them. See the 'HRTICK' scheduler feature. And for SCHED_FIFO that timeout can be 'never' - i.e. essentially stopping the scheduler tick. (within reason.) > Could we reduce the overhead by making the IN_USER vs IN_KERNEL > indication be a single bit and, worst case, an rdtsc and maybe a > subtraction? We could probably get away with banning full nohz on > non-invariant tsc systems. > > (I do understand why it would be tricky to transition from IN_USER > to IN_KERNEL with IRQs on. Solvable, maybe, but tricky.) We can make it literally zero overhead: by using an IPI from synchronize_rcu() and friend. Thanks, Ingo