[lkml]   [2009]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 5/5] proc: export more page flags in /proc/kpageflags
    > I think i have to NAK this kind of ad-hoc instrumentation of kernel 
    > internals and statistics until we clear up why such instrumentation

    I think because it has zero fast path overhead and can be used
    any time without enabling anything special.

    > measures are being accepted into the MM while other, more dynamic

    While the dynamic instrumentation you're proposing
    has non zero fast path overhead, especially if you consider the
    CPU time needed for the backend computation in user space too.

    And it requires explicit tracing first and some backend
    that counts the events and maintains a shadow data structure
    covering all of mem_map again.

    So it's clear your alternative will be much more costly, plus
    have additional drawbacks (needs enabling first, cannot
    take a snapshot at arbitary time)

    Also dynamic tracing tends to have trouble with full memory
    observation. I experimented with systemtap tracing for my
    memory usage paper I did a couple of years ago, but ended
    up with integrated counters (similar to those) because it was
    impossible to do proper accounting for the pages set up
    in early boot with the standard tracers.

    I suspect both have their uses (that's indeed some things
    that can only be done with dynamic tracing), but they're clearly
    complementary and the static facility seems useful enough
    on its own.

    I think Fengguang is demonstrating that clearly by the great
    improvements he's doing for readahead which are enabled by these


     \ /
      Last update: 2009-04-28 09:39    [W:0.020 / U:54.620 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site