lkml.org 
[lkml]   [2006]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Perfctr-devel] RE: [perfmon] Re: quick overview of the perfmon2 interface
    Bryan,

    On Wed, Jan 25, 2006 at 02:46:43PM -0800, Bryan O'Sullivan wrote:
    > On Wed, 2006-01-25 at 14:28 -0800, Stephane Eranian wrote:
    >
    > > So it would help if you could
    > > name the extended features you referring to.
    >
    > I'm dubious about the hands-off buffer format in general. Does this
    > mean that userspace needs to modprobe a specific set of modules in order
    > to do normal sampling? If so, how do you work around the need for users
    > to be root in order to use these interfaces?

    As I said, there is a builtin default format that is fairly generic. It does
    work for HP Caliper, pfmon, q-tools. I suspect it is good enough for VTUNE.

    You need to be root to insert the module. But I believe that for many user
    environments, this is more practical than having to recompile a custom kernel.
    You can imagine the format being shipped with the tool, when the sysadmin
    installs the tool it also installs the module.

    >
    > > And perfmon
    > > does allow it to continue working using almost all of its kernel code.
    > > This is leveraging the custom sampling buffer format support in perfmon.
    > > So you can say this is an extended feature that adds complexity.
    > > But OTOH, this is one elegant way of supporting an existing interface
    > > without breaking all the tools.
    >
    > So are you saying that part of the existing oprofile code can be deleted
    > if perfmon is merged, and that userspace won't notice?
    >
    The part of Oprofile that does actual programming of the PMU can be removed.
    The part that stays is the one that deals with recording samples, exporting
    samples, and collecting OS events such as exit, mmap, exec. As the user
    level, they need to migrated from the Oprofile way of programming counters
    to the perfmon way. This has been done many years ago on Itanium and did
    not cause any major problems.

    > > We were able to proide this support
    > > with a few hundred lines of code without hacking the regular sampling
    > > format. Instead we simply created a dedicated PEBS format as a kernel module.
    >
    > Does this mean I can't sample the PMCs on a P4 if I don't have the
    > special PEBS module loaded? Do I need to be root to do that?

    PEBS is a P4 feature that has two advantages:
    - record the exact IP of where a counter overflows (no skid)
    - the CPU directly record the samples into a memory area designated
    by the kernel. As such, you only get a PMU when that area fills up.

    There are some limitations:
    - you cannot sample on any event
    - the format of a sample is fixed, it does not contain extra PMDs, just
    IP and some general registers. The process id is not recorded
    so it is not well suited for system-wide monitoring.
    - it appears to broken for HyperThreading setups.

    So, it all depends on what you are after. Some people do care about avoiding
    the skid of regular sampling and they want they like PEBS just for that. Others
    would like to record a set of extra PMDs (PERFCTR) and they are willing to
    compromise a bit on the skid of IP, so they can live with the default format.

    --
    -Stephane
    -
    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/

    \
     
     \ /
      Last update: 2006-01-26 08:54    [W:4.311 / U:0.136 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site