Re: [PATCH 0/5] perf kmem: Add more functions and show more statistics

[Li Zefan]

Ingo Molnar wrote:
> * Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote:
> 
>> Hi Li,
>>
>> On Tue, Nov 24, 2009 at 7:25 AM, Li Zefan <lizf@xxxxxxxxxxxxxx> 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 <lizf@xxxxxxxxxxxxxx> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/