xfs
[Top] [All Lists]

Re: pagebuf_prepare_write doesn't kmap the page

To: Andi Kleen <ak@xxxxxxx>
Subject: Re: pagebuf_prepare_write doesn't kmap the page
From: Steve Lord <lord@xxxxxxx>
Date: Wed, 31 Jan 2001 11:43:25 -0600
Cc: marcelo@xxxxxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx
Comments: In-reply-to Andi Kleen <ak@suse.de> message dated "Wed, 31 Jan 2001 18:37:12 +0100."
References: <lord@sgi.com> <200101311643.f0VGhgR26778@jen.americas.sgi.com> <20010131183117.P508@suse.de> <20010131183712.A31126@gruyere.muc.suse.de>
Sender: owner-linux-xfs@xxxxxxxxxxx
> On Wed, Jan 31, 2001 at 06:31:17PM +0100, Jens Axboe wrote:
> > On Wed, Jan 31 2001, Steve Lord wrote:
> > > 
> > > To follow up on my own message - running some micro benchmarks, every sin
> gle
> > > individual operation got faster, but dbench got slower.....
> > 
> > Dbench being slower in 2.4.1 vs 2.4.0 would be quite normal, and
> > I wouldn't be alarmed if it's the only one disturbed by this. The
> > easy way to get screamer dbench numbers is to completely ignore
> > latency and finish one process I/O at the time only.
> 
> This sounds like it would be interesting to modify dbench to log average
> running times for individual processes. Then such latency changes could
> be catched.

One noticable change in dbench is that in 2.4.0 - and for a long time
prior to that, the individual dbench programs used to complete at widely
differing times, now they pretty much all get a fair share of the system
and we end up with them all running for about the same time. I suppose this
would mean more memory load on the system for the whole duration of the run,
where before the longer running threads got to run under lighter load once
the other threads had finished.

This would probably account for the slowdown.

Steve

> 
> 
> -Andi



<Prev in Thread] Current Thread [Next in Thread>