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: [email protected]
Phone: (650) 506-8127
Joel Becker <[email protected]> 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?
On Wed, Mar 19, 2003 at 05:57:26PM -0800, Andrew Morton wrote:
> Joel Becker <[email protected]> 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: [email protected]
Phone: (650) 506-8127
Joel Becker wrote:
>On Wed, Mar 19, 2003 at 05:57:26PM -0800, Andrew Morton wrote:
>
>>Joel Becker <[email protected]> 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.
On Wed, Mar 19 2003, Joel Becker wrote:
> On Wed, Mar 19, 2003 at 05:57:26PM -0800, Andrew Morton wrote:
> > Joel Becker <[email protected]> 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
Jens Axboe <[email protected]> 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.
On Thu, Mar 20 2003, Andrew Morton wrote:
> Jens Axboe <[email protected]> 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
Jens Axboe wrote:
>On Thu, Mar 20 2003, Andrew Morton wrote:
>
>>Jens Axboe <[email protected]> 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.
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: [email protected]
Phone: (650) 506-8127