[lkml]   [2008]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 21/24] perfmon: Intel architectural PMU support (x86)
    On Wed, 26 Nov 2008, stephane eranian wrote:
    > In anycase, the idea is to encapsulate as much as possible code
    > related into a PMU model
    > into each module. That is why you are seing some redundancy.

    Makes sense.

    > There is a difference between enable_mask and used_pmcs. The used_pmcs
    > bitmasks shows
    > all the config registers in use. Whereas enable_mask shows the all
    > config registers which have
    > start/stop capabilities. For the basic AMD64 PMU (4 counters)
    > used_pmcs and enable_mask
    > are equivalent, but that is not the case on Barcelona once we support
    > IBS and sampling. So
    > for now, I could clean this up and drop enable_mask to use plain used_pmcs.

    Understood. If we need that in the near future then it's ok to keep
    it, it just did not make any sense from the current code.

    But I think you should do this once when you set up the context and
    keep that as a separate mask. Right now you evaluate enable_mask and
    used_pmcs over and over again.

    > >> + count = pfm_arch_bv_weight(used_mask, max_enable);
    > >
    > > So we have:
    > >
    > > set->used_pmcs and enable_mask and max_enable.
    > >
    > > Why can set->used_pmcs contain bits which are not in the enable_mask
    > > in the first place ? Why does the arch code not tell the generic code
    > > which pmcs are available so we can avoid all this mask, weight
    > > whatever magic ?
    > >
    > Because used_pmcs is part of generic code and enable_mask is a x86 construct.
    > As I said above, for now, I could drop enable_mask.
    > The arch code already export the list of available pmcs and pmds in
    > impl_pmcs and impl_pmds.

    See above.

    > > Why are the counters enabled at all when an overflow is pending, which
    > > stopped the counters anyway ?
    > >
    > Because on Intel and AMD64, counters are not automatically frozen on interrupt.
    > On Intel X86, they can be configured to do so, but it is an all or
    > nothing setting.
    > I am not using this option because we would then have a problem with the NMI
    > watchdog given that it is also using a counter.

    Well, my question was: why do we have to stop the counters when an
    overflow is pending already ?

    The overflow pending is set inside of stop_save() and cleared
    somewhere else.

    stop_save() is called from pfm_arch_stop() and
    pfm_arch_ctxswout_thread(). The first thing it does is to disable the

    Now at some points the counters are obviously reenabled for this
    context, but why are they reenabled _before_ the pending overflow has
    been resolved ? For N counters that N * 2 wrmsrl() overhead.



     \ /
      Last update: 2008-11-26 17:13    [W:0.024 / U:4.168 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site