lkml.org 
[lkml]   [2004]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: CONFIG_PREEMPT and server workloads
    Takashi Iwai <tiwai@suse.de> wrote:
    >
    > > > --- linux-2.6.4-8/fs/jbd/commit.c-dist 2004-03-16 23:00:40.000000000 +0100
    > > > +++ linux-2.6.4-8/fs/jbd/commit.c 2004-03-18 02:42:41.043448624 +0100
    > > > @@ -290,6 +290,9 @@ write_out_data_locked:
    > > > commit_transaction->t_sync_datalist = jh;
    > > > break;
    > > > }
    > > > +
    > > > + if (need_resched())
    > > > + break;
    > > > } while (jh != last_jh);
    > > >
    > > > if (bufs || need_resched()) {
    > >
    > > This one I need to think about. Perhaps we can remove the yield point a
    > > few lines above.
    >
    > yes, i'm afraid that it's also overkill to check this at every time.
    > perhaps we can optimize it a bit better. the fact that it imporives
    > the latency means that there are so many locked buffers or non-dirty
    > buffers in the list?

    yes, lots of clean buffers.

    > > One needs to be really careful with the lock-dropping trick - there are
    > > weird situations in which the kernel fails to make any forward progress.
    > > I've been meaning to do another round of latency tuneups for ages, so I'll
    > > check this one out, thanks.
    > >
    > > There's also the SMP problem: this CPU could be spinning on a lock with
    > > need_resched() true, but the other CPU is hanging on the lock for ages
    > > because its need_resched() is false.
    >
    > yep, i see a similar problem also in reiserfs's do_journal_end().
    > it's in lock_kernel().

    I have a scheduling point in journal_end() in 2.4. But I added bugs to
    reiserfs a couple of times doing this - it's pretty delicate. Beat up on
    Chris ;)

    > > Last time I looked the worst-case latency is in fact over in the ext3
    > > checkpoint code. It's under spinlock and tricky to fix.
    >
    > BTW, i had the worst latency in sis900's timer handler.
    > it takes 3ms, and hard to fix, too :-<

    networking in general can cause problems, as can the random driver, which I
    hacked rather flakily in 2.4.

    davem fixed the tcp_minisock reaping in 2.6, which helps.
    -
    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: 2005-03-22 14:01    [W:0.026 / U:59.332 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site