| To: | Steve Lord <lord@xxxxxxx> |
|---|---|
| Subject: | Re: pagebuf_prepare_write doesn't kmap the page |
| From: | Jens Axboe <axboe@xxxxxxx> |
| Date: | Wed, 31 Jan 2001 18:49:14 +0100 |
| Cc: | Andi Kleen <ak@xxxxxxx>, marcelo@xxxxxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx |
| In-reply-to: | <200101311743.f0VHhPd32287@jen.americas.sgi.com>; from lord@sgi.com on Wed, Jan 31, 2001 at 11:43:25AM -0600 |
| References: | <lord@sgi.com> <200101311643.f0VGhgR26778@jen.americas.sgi.com> <20010131183117.P508@suse.de> <20010131183712.A31126@gruyere.muc.suse.de> <200101311743.f0VHhPd32287@jen.americas.sgi.com> |
| Sender: | owner-linux-xfs@xxxxxxxxxxx |
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. 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 ;-) -- Jens Axboe |
| Previous by Date: | Re: pagebuf_prepare_write doesn't kmap the page, Steve Lord |
|---|---|
| Next by Date: | Re: pagebuf_prepare_write doesn't kmap the page, Rajagopal Ananthanarayanan |
| Previous by Thread: | Re: pagebuf_prepare_write doesn't kmap the page, Steve Lord |
| Next by Thread: | Re: pagebuf_prepare_write doesn't kmap the page, Rajagopal Ananthanarayanan |
| Indexes: | [Date] [Thread] [Top] [All Lists] |