Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751811AbbEGPor (ORCPT ); Thu, 7 May 2015 11:44:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56506 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750863AbbEGPoo (ORCPT ); Thu, 7 May 2015 11:44:44 -0400 Message-ID: <554B8860.6010602@redhat.com> Date: Thu, 07 May 2015 11:44:32 -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: Frederic Weisbecker CC: paulmck@linux.vnet.ibm.com, Paolo Bonzini , Ingo Molnar , Andy Lutomirski , "linux-kernel@vger.kernel.org" , X86 ML , williams@redhat.com, Andrew Lutomirski , fweisbec@redhat.com, Peter Zijlstra , Heiko Carstens , Thomas Gleixner , Ingo Molnar , Linus Torvalds Subject: Re: question about RCU dynticks_nesting References: <20150502052733.GA9983@gmail.com> <55473B47.6080600@redhat.com> <55479749.7070608@redhat.com> <20150504183906.GS5381@linux.vnet.ibm.com> <5547CAED.9010201@redhat.com> <20150504200232.GB5381@linux.vnet.ibm.com> <5547D2FE.9010806@redhat.com> <20150504203801.GG5381@linux.vnet.ibm.com> <5547DC3C.1000504@redhat.com> <20150507005904.GA22006@lerouge> In-Reply-To: <20150507005904.GA22006@lerouge> 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: 2104 Lines: 46 On 05/06/2015 08:59 PM, Frederic Weisbecker wrote: > On Mon, May 04, 2015 at 04:53:16PM -0400, Rik van Riel wrote: >> Ingo's idea is to simply have cpu 0 check the current task >> on all other CPUs, see whether that task is running in system >> mode, user mode, guest mode, irq mode, etc and update that >> task's vtime accordingly. >> >> I suspect the runqueue lock is probably enough to do that, >> and between rcu state and PF_VCPU we probably have enough >> information to see what mode the task is running in, with >> just remote memory reads. > > Note that we could significantly reduce the overhead of vtime accounting > by only accumulate utime/stime on per cpu buffers and actually account it > on context switch or task_cputime() calls. That way we remove the overhead > of the account_user/system_time() functions and the vtime locks. > > But doing the accounting from CPU 0 by just accounting 1 tick to the context > we remotely observe would certainly reduce the local accounting overhead to the strict > minimum. And I think we shouldn't even lock rq for that, we can live with some > lack of precision. We can live with lack of precision, but we cannot live with data structures being re-used and pointers pointing off into la-la land while we are following them :) > Now we must expect quite some overhead on CPU 0. Perhaps it should be > an option as I'm not sure every full dynticks usecases want that. Lets see if I can get this to work before deciding whether we need yet another configurable option :) It may be possible to have most of the overhead happen from schedulable context, maybe softirq code. Right now I am still stuck in the giant spaghetti mess under account_process_tick, with dozens of functions that only work on cpu-local, task-local, or architecture dependently cpu or task local data... -- 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/