lkml.org 
[lkml]   [2010]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v2] tracing: shrink max latency ringbuffer if unnecessary
    From
    2010/7/1 Lai Jiangshan <laijs@cn.fujitsu.com>:
    > KOSAKI Motohiro wrote:
    >>
    >> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    >> ---
    >>  kernel/trace/trace.c              |   39 ++++++++++++++++++++++++++++++------
    >>  kernel/trace/trace.h              |    1 +
    >>  kernel/trace/trace_irqsoff.c      |    3 ++
    >>  kernel/trace/trace_sched_wakeup.c |    2 +
    >>  4 files changed, 38 insertions(+), 7 deletions(-)
    >>
    >
    > Reviewed-by: Lai Jiangshan <laijs@cn.fujitsu.com
    >
    >
    >> -
    >> +     if (current_trace && current_trace->use_max_tr) {
    >> +             /*
    >> +              * We don't free the ring buffer. instead, resize it because
    >> +              * The max_tr ring buffer has some state (e.g. ring->clock) and
    >> +              * we want preserve it.
    >> +              */
    >> +             ring_buffer_resize(max_tr.buffer, 1);
    >> +             max_tr.entries = 1;
    >> +     }
    >>       destroy_trace_option_files(topts);
    >>
    >>       current_trace = t;
    >>
    >>       topts = create_trace_option_files(current_trace);
    >
    > I think we can skip the two resize when current_trace->use_max_tr==1 && t->use_max_tr==1

    Yup. but I don't think it's worthful because it's rarely operation.


    >
    >> +     if (current_trace->use_max_tr) {
    >> +             ret = ring_buffer_resize(max_tr.buffer, global_trace.entries);
    >> +             if (ret < 0)
    >> +                     goto out;
    >> +             max_tr.entries = global_trace.entries;
    >> +     }
    >>
    >>       if (t->init) {
    >>               ret = tracer_init(t, tr);
    >
    > Does we need to shrink it when tracer_init() fails?
    > Although tracer_init() hardly fails, and there is no bad effect even we don't shrink it.

    Nope. brief code of tracing_set_tracer() is here

    ========================================
    if (current_trace && current_trace->reset)
    current_trace->reset(tr);

    destroy_trace_option_files(topts);

    current_trace = t;

    topts = create_trace_option_files(current_trace);

    if (t->init) {
    ret = tracer_init(t, tr);
    if (ret)
    goto out;
    }
    ========================================

    That's mean, if t->init fail, we can't rollback old tracer. so your
    suggested micro optimization
    doesn't makes observable improvement, I think.

    Thanks.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-07-01 13:51    [W:3.173 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site