[lkml]   [2008]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: debugctl msr
    >-----Original Message-----
    >From: stephane eranian []
    >Sent: Mittwoch, 12. November 2008 11:10
    >To: Markus Metzger

    >>> For perfmon, PEBS can be used for both per-thread and per-cpu. With
    >>> perfmon, the allocation/initialization of the buffer is
    >separated from its
    >>> activation. In other words, allocation/initialization may
    >be done before
    >>> you
    >>> actually have to write the DS_AREA MSR.
    >Allocation/initialization may not
    >>> necessary be done on the cpu you want to measure in per-cpu
    >mode. The
    >>> logic of DS is different, ds_request_pebs() allocates and
    >>> writes
    >>> DS_AREA. I cannot use that.
    >> DS_AREA contains a pointer to the actual configuration struct.
    >> The idea is that once I allocated the configuration struct,
    >I can write
    >> the pointer to it into DS_AREA. It won't be used unless I
    >turn on a feature
    >> that uses DS.
    >> So, the flow is:
    >> 1. allocate configuration struct
    >> 2. write DS_AREA
    >What if you are allocating the buffer for another task. For instance,
    >a tool is attaching
    >to a running process and wants to use PEBS. The tool allocates and
    >initializes the
    >PEBS buffer and then attaches it to the task to monitor (which is
    >stopped). When the
    >task is scheduled again, it picks up the PEBS buffer, and
    >DS_AREA is written to.

    That tool should request DS for the task it intends to attach its
    PEBS buffer to. Who knows, maybe PEBS is already in use for that task
    by someone else. Or maybe there is a system wide BTS or PEBS session
    and the per-task request would need to be rejected (until we can
    support this scenario).

    >There is another reason why the DS_AREA is exposed. This is
    >the only way for
    >tools to see the current position in the PEBS buffer. They may
    >want to poll on
    >that position index. The PEBS buffer is not necessarily full. What if
    >the session
    >terminates with a partial buffer. There must be a way for the
    >tool to figure out
    >where the last sample is. By exposing DS read-only the index
    >is always available
    >and always guaranteed current. Without this, the kernel would have to
    >extract the
    >index (pebs_get_index) and store it somewhere so the user can
    >see it. This copy
    >could be tirggered by a PEBS buffer overflow or a stop of
    >monitoring. Sampling
    >buffers formats currently do not have a stop callback but this can be
    >added easily.

    With the current interface, you would need to call ds_get_pebs_index().

    The rfc patch I sent out some weeks ago in the scope of multiplexing
    uses the approach you described - at least in-kernel.
    Upon ds_request_pebs(), you would get a const struct pebs_tracer* that
    contains a const view of the DS configuration.

    In any case, I think the DS configuration needs to be allocated by ds.c
    since we have two independent users that need to share a single

    Would it help if we changed the DS interface as proposed in that rfc
    patch (without all the multiplexing stuff)?

    Intel GmbH
    Dornacher Strasse 1
    85622 Feldkirchen/Muenchen Germany
    Sitz der Gesellschaft: Feldkirchen bei Muenchen
    Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
    Registergericht: Muenchen HRB 47456 Ust.-IdNr.
    VAT Registration No.: DE129385895
    Citibank Frankfurt (BLZ 502 109 00) 600119052

    This e-mail and any attachments may contain confidential material for
    the sole use of the intended recipient(s). Any review or distribution
    by others is strictly prohibited. If you are not the intended
    recipient, please contact the sender and delete all copies.

     \ /
      Last update: 2008-11-12 12:03    [W:0.027 / U:69.976 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site