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    [from the cache]
©2003-2011 Jasper Spaans