Re: CONFIG_PREEMPT and server workloads

[Chris Mason <mason@suse.com>]

On Fri, 2004-03-19 at 06:37, Takashi Iwai wrote:
> At Thu, 18 Mar 2004 14:48:07 -0500,
> Chris Mason wrote:
> > 
> > On Thu, 2004-03-18 at 14:29, Andrew Morton wrote:
> > 
> > > > 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 ;)
> > 
> > ;-) Not sure if Takashi is talking about -suse or -mm, the data=ordered
> > patches change things around.  He sent me suggestions for the
> > data=ordered latencies already, but it shouldn't be against the BKL
> > there, since I drop it before calling write_ordered_buffers().
> 
> i tested only suse kernels recently.  will try mm kernel later, again.
> 
> ok, let me explain some nasty points i found through the disk i/o load
> tests:
> 
> - in the loop in do_journal_end().  this happens periodically in
>   pdflush.
> 
This one we need.

> - in write_ordered_buffers().
> 
>   i still don't figure out where.  we have already cond_resched()
>   check in the loops.  this one is triggered when i write bulk data
>   in parallel (1GB write with 20 threads at the same time), resulting
>   in up to 2ms.
> 
Hmmm, is this a lock latency or just noticing that write() takes a long
time?

It's probably this:
	if (chunk.nr == 0 && need_resched) {

I'll bet the latencies go away when you drop the chunk.nr test.  If so
I'll need to benchmark if we want to submit before the schedule
(probably yes, as long as we've already sent down some buffers
previously).

(BTW, this code is only in the -suse patchset, data=ordered adds many
new places for possible latencies)

-chris