[lkml]   [2009]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/5] perf kmem: Add more functions and show more statistics
    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.

     \ /
      Last update: 2009-11-24 09:07    [W:0.030 / U:5.868 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site