From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751547AbbEBS2w (ORCPT ); Sat, 2 May 2015 14:28:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35692 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751149AbbEBS2u (ORCPT ); Sat, 2 May 2015 14:28:50 -0400 Message-ID: <5545172F.5090705@redhat.com> Date: Sat, 02 May 2015 14:27:59 -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 , "Paul E. McKenney" , Linus Torvalds Subject: Re: [PATCH 3/3] context_tracking,x86: remove extraneous irq disable & enable from context tracking on syscall entry References: <554399D1.6010405@redhat.com> <20150501155912.GA451@gmail.com> <20150501162109.GA1091@gmail.com> <5543A94B.3020108@redhat.com> <20150501163431.GB1327@gmail.com> <5543C05E.9040209@redhat.com> <20150501184025.GA2114@gmail.com> <5543CFE5.1030509@redhat.com> <20150502052733.GA9983@gmail.com> In-Reply-To: <20150502052733.GA9983@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 On 05/02/2015 01:27 AM, Ingo Molnar wrote: > Regarding the user/kernel execution time split measurement: > > 1) the same flag could be used to sample a remote CPU's statistics > from another CPU and update the stats in the currently executing task. > As long as there's at least one non-nohz-full CPU, this would work. Or > are there systems were all CPUs are nohz-full? On a NO_HZ_FULL system, you need at least one CPU to execute RCU callbacks, and do other system things like that, so there is at least one CPU that is not nohz_full. On NUMA systems, I could even see the sane option being one CPU that is not isolated or nohz_full per NUMA node, so we have a place to route irqs, etc... > 2) Alternatively we could just drive user/kernel split statistics from > context switches, which would be inaccurate if the workload is > SCHED_FIFO that only rarely context switches. > > How does this sound? I think option (1) sounds nicer :) What locks do we need, besides the runqueue lock to make sure the task does not go away, and later the task's vtime_lock to update its time statistics? Do we even need the lock_trace(task) as taken in proc_pid_stack(), since all we care is whether or not the thing is in kernel, user, or guest mode? For guest mode, we set a flag in the task struct somewhere, that part is easy. It also looks like dump_trace() can distinguish between normal, exception, and irq stacks. Not sure how fancy we need to get... -- All rights reversed