[Top] [All Lists]

Re: pagebuf_prepare_write doesn't kmap the page

To: linux-xfs@xxxxxxxxxxx
Subject: Re: pagebuf_prepare_write doesn't kmap the page
From: Rajagopal Ananthanarayanan <ananth@xxxxxxx>
Date: Wed, 31 Jan 2001 10:18:13 -0800
References: <lord@xxxxxxx> <200101311643.f0VGhgR26778@xxxxxxxxxxxxxxxxxxxx> <20010131183117.P508@xxxxxxx> <20010131183712.A31126@xxxxxxxxxxxxxxxxxxx> <200101311743.f0VHhPd32287@xxxxxxxxxxxxxxxxxxxx> <20010131184914.T508@xxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
Jens Axboe wrote:
> On Wed, Jan 31 2001, Steve Lord wrote:
> > 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.

Another datapoint. On a 2CPU 64MB system dbench  (48 clients) would
yield about 3.5-4.5 MB/sec on 2.4.0 ... with 2.4.1pre9 the same
setup would yield about 5+ MB/sec. The tests were run on ext2.

I too noticed that the individual threads were completing at about
the same time in 2.4.1pre9, as opposed to some threads finishing
really early in 2.4.0.

> This is exactly the reason as I outlined -- letting them complete
> without paying too much attention to latencies of individual dbench
> threads gives you much better results.
> dbench is a good benchmark, you just have to keep in mind what it
> measures and not just eat the numbers up raw ;-)

Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.

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