* WimMark I report for 2.5.65-mm2
@ 2003-03-19 23:28 Joel Becker
2003-03-20 1:57 ` Andrew Morton
0 siblings, 1 reply; 9+ messages in thread
From: Joel Becker @ 2003-03-19 23:28 UTC (permalink / raw)
To: linux-kernel
WimMark I report for 2.5.65-mm2
Runs: 1374.22 1487.19 1437.26
WimMark I is a rough benchmark we have been running
here at Oracle against various kernels. Each run tests an OLTP
workload on the Oracle database with somewhat restrictive memory
conditions. This reduces in-memory buffering of data, allowing for
more I/O. The I/O is read and sync write, random and seek-laden.
The benchmark is called "WimMark I" because it has no
official standing and is only a relative benchmark useful for comparing
kernel changes. The benchmark is normalized an arbitrary kernel, which
scores 1000.0. All other numbers are relative to this.
The machine in question is a 4 way 700 MHz Xeon machine with 2GB
of RAM. CONFIG_HIGHMEM4GB is selected. The disk accessed for data is a
10K RPM U2W SCSI of similar vintage. The data files are living on an
ext3 filesystem. Unless mentioned, all runs are
on this machine (variation in hardware would indeed change the
benchmark).
--
"Senator let's be sincere,
As much as you can."
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: WimMark I report for 2.5.65-mm2
2003-03-20 1:57 ` Andrew Morton
@ 2003-03-20 0:38 ` Joel Becker
2003-03-20 0:55 ` Nick Piggin
2003-03-20 8:04 ` Jens Axboe
0 siblings, 2 replies; 9+ messages in thread
From: Joel Becker @ 2003-03-20 0:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Wed, Mar 19, 2003 at 05:57:26PM -0800, Andrew Morton wrote:
> Joel Becker <Joel.Becker@oracle.com> wrote:
> >
> > WimMark I report for 2.5.65-mm2
> >
> > Runs: 1374.22 1487.19 1437.26
> >
>
> That is with elevator=as?
Yes, it is as. On Nick's recommendation I didn't consider a
deadline run a priority. The regular deadline runs have been 1550-1590,
which is indeed statistically significant.
Joel
--
"In the beginning, the universe was created. This has made a lot
of people very angry, and is generally considered to have been a
bad move."
- Douglas Adams
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: WimMark I report for 2.5.65-mm2
2003-03-20 0:38 ` Joel Becker
@ 2003-03-20 0:55 ` Nick Piggin
2003-03-20 8:04 ` Jens Axboe
1 sibling, 0 replies; 9+ messages in thread
From: Nick Piggin @ 2003-03-20 0:55 UTC (permalink / raw)
To: Joel Becker; +Cc: Andrew Morton, linux-kernel
Joel Becker wrote:
>On Wed, Mar 19, 2003 at 05:57:26PM -0800, Andrew Morton wrote:
>
>>Joel Becker <Joel.Becker@oracle.com> wrote:
>>
>>>WimMark I report for 2.5.65-mm2
>>>
>>>Runs: 1374.22 1487.19 1437.26
>>>
>>>
>>That is with elevator=as?
>>
>
> Yes, it is as. On Nick's recommendation I didn't consider a
>deadline run a priority. The regular deadline runs have been 1550-1590,
>which is indeed statistically significant.
>
Well this is getting better which is good. I think we could make sync
writes in the stream even less favourable for anticipation, however
it might be doing bad things to contest dbench. Needs investigation.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: WimMark I report for 2.5.65-mm2
2003-03-19 23:28 WimMark I report for 2.5.65-mm2 Joel Becker
@ 2003-03-20 1:57 ` Andrew Morton
2003-03-20 0:38 ` Joel Becker
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Morton @ 2003-03-20 1:57 UTC (permalink / raw)
To: Joel Becker; +Cc: linux-kernel
Joel Becker <Joel.Becker@oracle.com> wrote:
>
> WimMark I report for 2.5.65-mm2
>
> Runs: 1374.22 1487.19 1437.26
>
That is with elevator=as?
Is this a statistically significant difference from elevator=deadline?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: WimMark I report for 2.5.65-mm2
2003-03-20 0:38 ` Joel Becker
2003-03-20 0:55 ` Nick Piggin
@ 2003-03-20 8:04 ` Jens Axboe
2003-03-20 8:20 ` Andrew Morton
1 sibling, 1 reply; 9+ messages in thread
From: Jens Axboe @ 2003-03-20 8:04 UTC (permalink / raw)
To: Joel Becker; +Cc: Andrew Morton, linux-kernel
On Wed, Mar 19 2003, Joel Becker wrote:
> On Wed, Mar 19, 2003 at 05:57:26PM -0800, Andrew Morton wrote:
> > Joel Becker <Joel.Becker@oracle.com> wrote:
> > >
> > > WimMark I report for 2.5.65-mm2
> > >
> > > Runs: 1374.22 1487.19 1437.26
> > >
> >
> > That is with elevator=as?
>
> Yes, it is as. On Nick's recommendation I didn't consider a
> deadline run a priority. The regular deadline runs have been 1550-1590,
> which is indeed statistically significant.
Hmm that's a bit odd IMHO, the deadline runs are nice for comparison. If
there's a variation between -mmX and -mmY, and deadline + as have
consistent scores, then it would be a good clue.
Besides, deadline is still the most solid choice.
--
Jens Axboe
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: WimMark I report for 2.5.65-mm2
2003-03-20 8:04 ` Jens Axboe
@ 2003-03-20 8:20 ` Andrew Morton
2003-03-20 8:29 ` Jens Axboe
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Morton @ 2003-03-20 8:20 UTC (permalink / raw)
To: Jens Axboe; +Cc: Joel.Becker, linux-kernel
Jens Axboe <axboe@suse.de> wrote:
>
> Besides, deadline is still the most solid choice.
Deadline will always be the best choice for OLTP workloads. Or CFQ - it
should perform the same.
All this workload does is seeks all over the disk doing teeny synchronous
I/O's. It is the worst-case for AS.
What we are trying to do at present is to make AS not _too_ bad for these
workloads so that people with mixed workloads or who are not familiar with
kernel arcanery don't accidentally end up with something which is
significantly slower than it should be.
It is an interesting test case.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: WimMark I report for 2.5.65-mm2
2003-03-20 8:20 ` Andrew Morton
@ 2003-03-20 8:29 ` Jens Axboe
2003-03-20 15:01 ` Nick Piggin
0 siblings, 1 reply; 9+ messages in thread
From: Jens Axboe @ 2003-03-20 8:29 UTC (permalink / raw)
To: Andrew Morton; +Cc: Joel.Becker, linux-kernel
On Thu, Mar 20 2003, Andrew Morton wrote:
> Jens Axboe <axboe@suse.de> wrote:
> >
> > Besides, deadline is still the most solid choice.
>
> Deadline will always be the best choice for OLTP workloads. Or CFQ - it
> should perform the same.
>
> All this workload does is seeks all over the disk doing teeny synchronous
> I/O's. It is the worst-case for AS.
>
> What we are trying to do at present is to make AS not _too_ bad for these
> workloads so that people with mixed workloads or who are not familiar with
> kernel arcanery don't accidentally end up with something which is
> significantly slower than it should be.
>
> It is an interesting test case.
I understand that. A deadline run is still interesting if there are
regressions from -mm2 to -mm3, for example. If deadline shows the same
regression, it's likely not a newly introduced AS bug.
--
Jens Axboe
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: WimMark I report for 2.5.65-mm2
2003-03-20 8:29 ` Jens Axboe
@ 2003-03-20 15:01 ` Nick Piggin
2003-03-20 18:32 ` Joel Becker
0 siblings, 1 reply; 9+ messages in thread
From: Nick Piggin @ 2003-03-20 15:01 UTC (permalink / raw)
To: Jens Axboe; +Cc: Andrew Morton, Joel.Becker, linux-kernel
Jens Axboe wrote:
>On Thu, Mar 20 2003, Andrew Morton wrote:
>
>>Jens Axboe <axboe@suse.de> wrote:
>>
>>>Besides, deadline is still the most solid choice.
>>>
>>Deadline will always be the best choice for OLTP workloads. Or CFQ - it
>>should perform the same.
>>
>>All this workload does is seeks all over the disk doing teeny synchronous
>>I/O's. It is the worst-case for AS.
>>
>>What we are trying to do at present is to make AS not _too_ bad for these
>>workloads so that people with mixed workloads or who are not familiar with
>>kernel arcanery don't accidentally end up with something which is
>>significantly slower than it should be.
>>
>>It is an interesting test case.
>>
>
>I understand that. A deadline run is still interesting if there are
>regressions from -mm2 to -mm3, for example. If deadline shows the same
>regression, it's likely not a newly introduced AS bug.
>
You are quite right of course, Jens. I did tell Joel not to worry
about the other schedulers for a while just while I was trying to
get AS even close to their performance. I thought it would take a
bit longer to get there. It appears to be now, so yes, deadline
runs will be nice.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: WimMark I report for 2.5.65-mm2
2003-03-20 15:01 ` Nick Piggin
@ 2003-03-20 18:32 ` Joel Becker
0 siblings, 0 replies; 9+ messages in thread
From: Joel Becker @ 2003-03-20 18:32 UTC (permalink / raw)
To: Nick Piggin; +Cc: Jens Axboe, Andrew Morton, linux-kernel
On Fri, Mar 21, 2003 at 02:01:35AM +1100, Nick Piggin wrote:
> You are quite right of course, Jens. I did tell Joel not to worry
> about the other schedulers for a while just while I was trying to
> get AS even close to their performance. I thought it would take a
> bit longer to get there. It appears to be now, so yes, deadline
> runs will be nice.
Not a problem. I'm gonna do the -mm2 run right now.
Joel
--
Life's Little Instruction Book #80
"Slow dance"
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-03-20 18:22 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-19 23:28 WimMark I report for 2.5.65-mm2 Joel Becker
2003-03-20 1:57 ` Andrew Morton
2003-03-20 0:38 ` Joel Becker
2003-03-20 0:55 ` Nick Piggin
2003-03-20 8:04 ` Jens Axboe
2003-03-20 8:20 ` Andrew Morton
2003-03-20 8:29 ` Jens Axboe
2003-03-20 15:01 ` Nick Piggin
2003-03-20 18:32 ` Joel Becker
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.