[lkml]   [2004]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [profile] amortize atomic hit count increments
    William Lee Irwin III <> wrote:
    >> read_proc_profile()
    >> does not flush the per-cpu hashtables because flushing may cause
    >> timeslice overrun on the systems where prof_buffer cacheline bounces
    >> are so problematic as to livelock the timer interrupt.

    On Mon, Sep 13, 2004 at 10:05:21PM -0700, Andrew Morton wrote:
    > That's a bit of a problem, isn't it? As we can accumulate an arbitrarily
    > large number of hits within the hash table is it not possible that the
    > /proc/profile results could be grossly inaccurate?
    > If you had two front-ends per cpu to the profiling buffer then the CPU
    > which is running the /proc/profile read could tell all the other CPUs to
    > flip to their alternate buffer and can then perform accumulation at its
    > leisure.

    This is superior to no flushing; I'll implement that and send out an
    incremental update (or if preferred, an update of this patch).

    On Mon, Sep 13, 2004 at 10:05:21PM -0700, Andrew Morton wrote:
    > How does oprofile get around this? I guess in most modes the CPUs are not
    > synchronised.
    > One wonders how long we should keep flogging the /prof/profile profiling
    > code. What systems are seeing this livelock?

    The original bits were merely a consolidation extracted from a since-
    dropped feature patch and an unrelated feature patch from mingo and
    arjanv; this is an unrelated fix for SGI's stability issue on larger
    Altixen. I personally intend to do no further adjustments.

    -- wli
    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-03-22 14:06    [W:0.021 / U:9.772 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site