[lkml]   [2009]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/4] workqueue_tracepoint: Add worklet tracepoints for worklet lifecycle tracing
    On Sat, 25 Apr 2009 02:37:03 +0200
    Frederic Weisbecker <> wrote:

    > I discovered it with this tracer. Then it brought me to
    > write this patch:
    > ...
    > Still with these same observations, I wrote this another one:

    OK, it's great that you're working to improve the workqueue code. But
    does this justify permanently adding debug code to the core workqueue
    code? In fact, because you've discovered these problem, the reasons
    for adding the debug code have lessened!

    What we need are curious developers looking into how well subsystems
    are performing and how well callers are using them. Adding fairly
    large amounts of permanent debug code into the core subsystems is a
    peculiar way of encouraging such activity.

    If a developer is motivated to improve (say) workqueues then they will
    write a bit of ad-hoc code, or poke at it with systemtap or will
    maintain a private ftrace patch - that's all pretty simple stuff for
    such people.

    So what is the remaining case for adding these patches? What I see is

    a) that their presence will entice people to run them and maybe find
    some problems and

    b) the workqueue-maintainer's task is lessened a bit by not having
    to forward-port his debugging patch.

    I dunno, it all seems a bit thin to me. Especially when you multiply
    it all by nr_core_subsystems?

     \ /
      Last update: 2009-04-25 03:43    [W:0.024 / U:2.708 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site