From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757828AbZKXIEt (ORCPT ); Tue, 24 Nov 2009 03:04:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757660AbZKXIEs (ORCPT ); Tue, 24 Nov 2009 03:04:48 -0500 Received: from cn.fujitsu.com ([222.73.24.84]:61997 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1757628AbZKXIEr (ORCPT ); Tue, 24 Nov 2009 03:04:47 -0500 Message-ID: <4B0B937F.4080906@cn.fujitsu.com> Date: Tue, 24 Nov 2009 16:04:15 +0800 From: Li Zefan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Ingo Molnar CC: Pekka Enberg , Arjan van de Ven , Eduard - Gabriel Munteanu , Peter Zijlstra , Frederic Weisbecker , LKML , "linux-mm@kvack.org" Subject: Re: [PATCH 0/5] perf kmem: Add more functions and show more statistics References: <4B0B6E44.6090106@cn.fujitsu.com> <84144f020911232315h7c8b7348u9ad97f585f54a014@mail.gmail.com> <20091124073426.GA21991@elte.hu> In-Reply-To: <20091124073426.GA21991@elte.hu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ingo Molnar wrote: > * Pekka Enberg wrote: > >> Hi Li, >> >> On Tue, Nov 24, 2009 at 7:25 AM, Li Zefan wrote: >>> Pekka, do you think we can remove kmemtrace now? >> One more use case I forgot to mention: boot time tracing. Much of the >> persistent kernel memory footprint comes from the boot process which >> is why it's important to be able to trace memory allocations >> immediately after kmem_cache_init() has run. Can we make "perf kmem" >> do that? Eduard put most of his efforts into making that work for >> kmemtrace. > > Would be lovely if someone looked at perf from that angle (and extended > it). > > Another interesting area would be to allow a capture session without a > process context running immediately. (i.e. pre-allocate all the buffers, > use them, for a later 'perf save' to pick it up.) > > The two are kind of the same thing conceptually: a boot time trace is a > preallocated 'process context less' recording, to be picked up after > bootup. > > [ It also brings us 'stability/persistency of event logging' - i.e. a > capture session could be started and guaranteed by the kernel to be > underway, regardless of what user-space does. ] > > Btw., Arjan is doing a _lot_ of boot time tracing for Moblin, and he > indicated it in the past that starting a perf recording session from an > initrd is a pretty practical substitute as well. (I've Cc:-ed Arjan.) > It would be great if perf can be used for boot time tracing. This needs pretty big work on kernel side. >> On Tue, Nov 24, 2009 at 7:25 AM, Li Zefan wrote: >> >>> With kmem trace events, low-level analyzing can be done using >>> ftrace, and high-level analyzing can be done using perf-kmem. >>> >>> And chance is, more people may use and improve perf-kmem, and it >>> will be well-maintained within the perf infrastructure. On the other >>> hand, I guess few people use and contribute to kmemtrace-user. >> Sure, I think "perf kmem" is the way forward. I'd love to hear >> Eduard's comments on this before we remove the code from kernel. Do we >> need to do that for 2.6.33 or can we postpone that for 2.6.34? > > Certainly we can postpone it, as long as there's rough strategic > consensus on the way forward. I'd hate to have two overlapping core > kernel facilities and friction between the groups pursuing them and > constant distraction from having two targets. > > Such situations just rarely end with a good solution for the user - see > security modules for a horror story ... > > [ I dont think it will occur here, just wanted to mention it out of > abundance of caution that 1.5 decades of kernel hacking experience > inflicts on me ;-) ] > Yeah, so we'd like to remove most of tracers, but I'm not rushing to remove kmemtrace for .33. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19]) by kanga.kvack.org (Postfix) with SMTP id 5079E6B0087 for ; Tue, 24 Nov 2009 03:04:56 -0500 (EST) Message-ID: <4B0B937F.4080906@cn.fujitsu.com> Date: Tue, 24 Nov 2009 16:04:15 +0800 From: Li Zefan MIME-Version: 1.0 Subject: Re: [PATCH 0/5] perf kmem: Add more functions and show more statistics References: <4B0B6E44.6090106@cn.fujitsu.com> <84144f020911232315h7c8b7348u9ad97f585f54a014@mail.gmail.com> <20091124073426.GA21991@elte.hu> In-Reply-To: <20091124073426.GA21991@elte.hu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: Ingo Molnar Cc: Pekka Enberg , Arjan van de Ven , Eduard - Gabriel Munteanu , Peter Zijlstra , Frederic Weisbecker , LKML , "linux-mm@kvack.org" List-ID: Ingo Molnar wrote: > * Pekka Enberg wrote: > >> Hi Li, >> >> On Tue, Nov 24, 2009 at 7:25 AM, Li Zefan wrote: >>> Pekka, do you think we can remove kmemtrace now? >> One more use case I forgot to mention: boot time tracing. Much of the >> persistent kernel memory footprint comes from the boot process which >> is why it's important to be able to trace memory allocations >> immediately after kmem_cache_init() has run. Can we make "perf kmem" >> do that? Eduard put most of his efforts into making that work for >> kmemtrace. > > Would be lovely if someone looked at perf from that angle (and extended > it). > > Another interesting area would be to allow a capture session without a > process context running immediately. (i.e. pre-allocate all the buffers, > use them, for a later 'perf save' to pick it up.) > > The two are kind of the same thing conceptually: a boot time trace is a > preallocated 'process context less' recording, to be picked up after > bootup. > > [ It also brings us 'stability/persistency of event logging' - i.e. a > capture session could be started and guaranteed by the kernel to be > underway, regardless of what user-space does. ] > > Btw., Arjan is doing a _lot_ of boot time tracing for Moblin, and he > indicated it in the past that starting a perf recording session from an > initrd is a pretty practical substitute as well. (I've Cc:-ed Arjan.) > It would be great if perf can be used for boot time tracing. This needs pretty big work on kernel side. >> On Tue, Nov 24, 2009 at 7:25 AM, Li Zefan wrote: >> >>> With kmem trace events, low-level analyzing can be done using >>> ftrace, and high-level analyzing can be done using perf-kmem. >>> >>> And chance is, more people may use and improve perf-kmem, and it >>> will be well-maintained within the perf infrastructure. On the other >>> hand, I guess few people use and contribute to kmemtrace-user. >> Sure, I think "perf kmem" is the way forward. I'd love to hear >> Eduard's comments on this before we remove the code from kernel. Do we >> need to do that for 2.6.33 or can we postpone that for 2.6.34? > > Certainly we can postpone it, as long as there's rough strategic > consensus on the way forward. I'd hate to have two overlapping core > kernel facilities and friction between the groups pursuing them and > constant distraction from having two targets. > > Such situations just rarely end with a good solution for the user - see > security modules for a horror story ... > > [ I dont think it will occur here, just wanted to mention it out of > abundance of caution that 1.5 decades of kernel hacking experience > inflicts on me ;-) ] > Yeah, so we'd like to remove most of tracers, but I'm not rushing to remove kmemtrace for .33. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org