lkml.org 
[lkml]   [2009]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: workqueue thing
    Hello, Ingo.

    On 12/23/2009 03:02 PM, Ingo Molnar wrote:
    > Not from lack of trying though ;-)
    >
    > One key thing i havent seen in this discussion are actual measurements. I
    > think a lot could be decided by simply testing this patch-set, by looking at
    > the hard numbers: how much faster (or slower) did a particular key workload
    > get before/after these patches.

    As Jeff pointed out, I don't think this is gonna result in any major
    performance increase or decrease. The upside would be lowered cache
    pressure coming from different types of works sharing the same context
    (this will be very difficult to measure). The downside would be the
    more complex code workqueue has to run to manage the shared pool. I
    don't think it's gonna be anything noticeable either way. Anyways, I
    can try to set up a synthetic case which involves a lot of work
    executions and at least make sure there's no noticeable slow down.

    > Likewise, if there's a reduction in complexity, that is a tangible metric as
    > well: lets do a few conversions as part of the patch-set and see how much
    > simpler things have become as a result of it.

    Doing several conversions shouldn't be difficult at all. I'll try to
    convert async and slow work.

    > We really are not forced to the space of Gedankenexperiments here.

    Sure but there's a reason why I posted the patchset without the actual
    conversions. I wanted to make sure that it's not rejected on the
    ground of its basic design. I thought it was acceptable after the
    first RFC round but while trying to merge the scheduler part, Peter
    seemed mightily unhappy with the whole thing, so this second RFC
    round. So, if anyone has major issues with the basic design, please
    step forward *now* before I go spending more time working on it.

    Another thing is that after spending a couple of months polishing the
    patchset, it feels quite tiring to keep the patchset floating (you
    know - Oh, this new thing should be merged into this patch. Dang, now
    I have to refresh 15 patches on top of it). I would really appreciate
    if I can set up a stable tree. Would it be possible to set up a sched
    devel branch?

    Thanks.

    --
    tejun


    \
     
     \ /
      Last update: 2009-12-23 08:09    [from the cache]
    ©2003-2011 Jasper Spaans