[lkml]   [2005]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2.6.12-rc1-mm5 1/3] perfctr: ppc64 arch hooks
    Andrew Morton writes:
    > David Gibson <> wrote:
    > >
    > > On Thu, Mar 31, 2005 at 03:11:29PM -0800, Andrew Morton wrote:
    > > > Mikael Pettersson <> wrote:
    > > > >
    > > > > Here's a 3-part patch kit which adds a ppc64 driver to perfctr,
    > > > > written by David Gibson <>.
    > > >
    > > > Well that seems like progress. Where do we feel that we stand wrt
    > > > preparedness for merging all this up?
    > >
    > > I'm still uneasy about it. There were sufficient changes made getting
    > > this one ready to go that I'm not confident there aren't more
    > > important things to be found.
    > That's a bit open-ended. How do we determine whether more things will be
    > needed? How do we know when we're done?

    I have two planned changes that will be done RSN:
    - On x86/x86-64, user-space uses the mmap()ed state's TSC start
    value as a way to detect if a user-space sampling operation
    (which needs to be "virtually atomic") was preempted by the kernel.
    On ppc{32,64} we've used the TB for the same thing up to now,
    but that doesn't quite work because the TB is about a magnitude
    or two too slow. So the plan is to change ppc to store a
    software generation counter in the mmap()ed state, and change
    the ppc user-space to check that one instead.
    - Move <asm-$arch/perfctr.h> common stuff to <asm-generic/perfctr.h>.

    In addition, there is one unresolved issue:
    - A counter's value is represented by a 64-bit software sum,
    a 32-bit start value containing the HW counter's value at the
    start of the current time slice, and the current HW counter's value
    (now). The actual value is computed as sum + (now - start).
    This is reflected in the mmap()ed state, which contains a variable-
    length { u32 map; u32 start; u64 sum; } pmc[] array.
    This layout is very cache-efficient on current 32 and 64-bit CPUs,
    but there is a _possible_ concern that it won't do on 10+ GHz CPUs.
    So the question is, should we change it to use 64-bit start values
    already now (and take more cache misses), or should that wait a few
    years until it becomes a necessity (causing ABI change issues)?

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-04-06 13:31    [W:0.022 / U:18.852 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site