* [BENCHMARK] 2.5.70-mm2 with contest
@ 2003-06-02 22:06 Con Kolivas
2003-06-02 22:16 ` Andrew Morton
0 siblings, 1 reply; 6+ messages in thread
From: Con Kolivas @ 2003-06-02 22:06 UTC (permalink / raw)
To: linux kernel mailing list; +Cc: Andrew Morton, Nick Piggin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
no_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.69 1 80 93.8 0.0 0.0 1.00
2.5.69-mm3 1 79 94.9 0.0 0.0 1.00
2.5.69-mm5 1 79 94.9 0.0 0.0 1.00
2.5.69-mm6 1 78 96.2 0.0 0.0 1.00
2.5.70 1 79 94.9 0.0 0.0 1.00
2.5.70-mm2 1 78 94.9 0.0 0.0 1.00
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.69 1 76 98.7 0.0 0.0 0.95
2.5.69-mm3 1 76 98.7 0.0 0.0 0.96
2.5.69-mm5 1 76 98.7 0.0 0.0 0.96
2.5.69-mm6 1 76 98.7 0.0 0.0 0.97
2.5.70 1 75 98.7 0.0 0.0 0.95
2.5.70-mm2 1 75 98.7 0.0 0.0 0.96
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.69 2 181 41.4 196.5 58.0 2.26
2.5.69-mm3 2 176 42.0 183.0 56.2 2.23
2.5.69-mm5 2 176 42.6 182.5 55.7 2.23
2.5.69-mm6 2 176 42.0 184.5 55.7 2.26
2.5.70 2 109 67.9 63.5 28.4 1.38
2.5.70-mm2 2 108 68.5 65.5 28.7 1.38
Same changes put into 2.5.70 are evident in mm2
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.69 3 103 75.7 0.0 0.0 1.29
2.5.69-mm3 3 126 63.5 1.0 4.8 1.59
2.5.69-mm5 3 114 70.2 1.0 5.3 1.44
2.5.69-mm6 3 112 70.5 1.0 5.4 1.44
2.5.70 3 103 75.7 0.0 0.0 1.30
2.5.70-mm2 3 118 66.9 1.0 5.1 1.51
probably not statistically significant
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.69 3 106 72.6 1.0 3.7 1.32
2.5.69-mm3 3 111 69.4 1.7 4.5 1.41
2.5.69-mm5 3 102 75.5 1.0 4.9 1.29
2.5.69-mm6 3 107 72.0 1.3 4.7 1.37
2.5.70 3 106 72.6 1.0 3.8 1.34
2.5.70-mm2 3 123 61.8 2.0 4.8 1.58
small rise in time with multiple small file extraction
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.69 4 343 22.7 120.5 19.8 4.29
2.5.69-mm3 4 319 24.5 105.3 18.1 4.04
2.5.69-mm5 4 137 56.9 49.6 19.0 1.73
2.5.69-mm6 4 150 52.0 53.4 18.7 1.92
2.5.70 5 326 21.5 112.9 18.7 4.13
2.5.70-mm2 4 115 67.0 42.0 19.1 1.47
large drop in time with one large file write
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.69 2 127 61.4 55.5 24.4 1.59
2.5.69-mm3 2 133 58.6 47.1 18.7 1.68
2.5.69-mm5 2 115 67.8 46.4 20.7 1.46
2.5.69-mm6 2 120 65.0 50.9 21.5 1.54
2.5.70 2 122 63.9 53.8 22.1 1.54
2.5.70-mm2 2 113 68.1 46.2 20.4 1.45
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.69 2 104 75.0 6.3 4.8 1.30
2.5.69-mm3 2 113 69.9 9.1 6.1 1.43
2.5.69-mm5 2 113 69.9 9.0 6.2 1.43
2.5.69-mm6 2 115 68.7 9.1 6.1 1.47
2.5.70 2 104 75.0 6.3 4.8 1.32
2.5.70-mm2 2 106 73.6 8.2 5.7 1.36
seems to correlate with .70 changes
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.69 2 95 81.1 0.0 5.3 1.19
2.5.69-mm3 2 95 81.1 0.0 7.4 1.20
2.5.69-mm5 2 96 80.2 0.0 7.3 1.22
2.5.69-mm6 2 96 80.2 0.0 7.3 1.23
2.5.70 2 96 80.2 0.0 7.3 1.22
2.5.70-mm2 2 94 81.9 0.0 7.4 1.21
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.69 2 98 79.6 60.5 2.0 1.23
2.5.69-mm3 2 135 59.3 77.0 2.2 1.71
2.5.69-mm5 2 99 79.8 53.0 2.0 1.25
2.5.69-mm6 2 100 79.0 60.0 2.0 1.28
2.5.70 2 97 80.4 53.5 2.1 1.23
2.5.70-mm2 2 99 78.8 54.5 2.0 1.27
dbench_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.69 4 374 20.3 5.0 48.1 4.67
2.5.69-mm3 4 653 11.6 6.2 34.0 8.27
2.5.69-mm5 4 316 24.1 4.0 44.6 4.00
2.5.69-mm6 4 386 19.9 5.2 48.4 4.95
2.5.70 5 321 22.1 4.0 44.5 4.06
2.5.70-mm2 4 305 24.9 4.8 55.4 3.91
I tried getting runs on 2.5.69-mm9 and 2.5.70-mm1 but ran into BUGs that have
been reported before on lkml.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+28p4F6dfvkL3i1gRAvsgAJ4mf8syPqOXkNt+tuNaoFgdMQZ8KQCdH/Er
wWRW9HrkWqpd9UTIeR/Lzz4=
=ly6r
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BENCHMARK] 2.5.70-mm2 with contest
2003-06-02 22:06 [BENCHMARK] 2.5.70-mm2 with contest Con Kolivas
@ 2003-06-02 22:16 ` Andrew Morton
2003-06-03 0:30 ` Nick Piggin
2003-06-03 0:44 ` Pasi Savolainen
0 siblings, 2 replies; 6+ messages in thread
From: Andrew Morton @ 2003-06-02 22:16 UTC (permalink / raw)
To: Con Kolivas; +Cc: linux-kernel, piggin
Con Kolivas <kernel@kolivas.org> wrote:
>
> io_load:
> Kernel [runs] Time CPU% Loads LCPU% Ratio
> 2.5.69 4 343 22.7 120.5 19.8 4.29
> 2.5.69-mm3 4 319 24.5 105.3 18.1 4.04
> 2.5.69-mm5 4 137 56.9 49.6 19.0 1.73
> 2.5.69-mm6 4 150 52.0 53.4 18.7 1.92
> 2.5.70 5 326 21.5 112.9 18.7 4.13
> 2.5.70-mm2 4 115 67.0 42.0 19.1 1.47
> large drop in time with one large file write
We're hitting nearly 90% CPU here. That is really excellent.
> I tried getting runs on 2.5.69-mm9 and 2.5.70-mm1 but ran into BUGs that have
> been reported before on lkml.
mm3 should be OK. After several days more testing I have not found any
bugs in mm3's ext3 which are not already in 2.5.70 ;)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BENCHMARK] 2.5.70-mm2 with contest
2003-06-02 22:16 ` Andrew Morton
@ 2003-06-03 0:30 ` Nick Piggin
2003-06-03 0:54 ` Andrew Morton
2003-06-03 0:44 ` Pasi Savolainen
1 sibling, 1 reply; 6+ messages in thread
From: Nick Piggin @ 2003-06-03 0:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: Con Kolivas, linux-kernel
Andrew Morton wrote:
>Con Kolivas <kernel@kolivas.org> wrote:
>
>>io_load:
>>Kernel [runs] Time CPU% Loads LCPU% Ratio
>>2.5.69 4 343 22.7 120.5 19.8 4.29
>>2.5.69-mm3 4 319 24.5 105.3 18.1 4.04
>>2.5.69-mm5 4 137 56.9 49.6 19.0 1.73
>>2.5.69-mm6 4 150 52.0 53.4 18.7 1.92
>>2.5.70 5 326 21.5 112.9 18.7 4.13
>>2.5.70-mm2 4 115 67.0 42.0 19.1 1.47
>>large drop in time with one large file write
>>
>
>We're hitting nearly 90% CPU here. That is really excellent.
>
Yes, the contest results have held up nicely after those big
changes to AS which is good.
It will be interesting to see what happens if we set the
ext3 journal write paths as PF_SYNCWRITE. I'll try some tests
a bit later today.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BENCHMARK] 2.5.70-mm2 with contest
2003-06-02 22:16 ` Andrew Morton
2003-06-03 0:30 ` Nick Piggin
@ 2003-06-03 0:44 ` Pasi Savolainen
1 sibling, 0 replies; 6+ messages in thread
From: Pasi Savolainen @ 2003-06-03 0:44 UTC (permalink / raw)
To: linux-kernel
* Andrew Morton <akpm@digeo.com>:
>> I tried getting runs on 2.5.69-mm9 and 2.5.70-mm1 but ran into BUGs that have
>> been reported before on lkml.
>
> mm3 should be OK. After several days more testing I have not found any
> bugs in mm3's ext3 which are not already in 2.5.70 ;)
I've hit assertion() /fs/jbd/transaction.c:1115 several times. Can't
tell anything else, as immediately after this keyboard gets locked, X still
reacts on _mouse_ (copy/paste thing) , but probably after hitting
disk/filesystem every application locks. for example cpu load meter
which open-read /proc gets frozen right away.
/var/log/messages doesn't tell a thing. Seems random.
kernel 2.5.70-mm3.
--
Psi -- <http://www.iki.fi/pasi.savolainen>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BENCHMARK] 2.5.70-mm2 with contest
2003-06-03 0:30 ` Nick Piggin
@ 2003-06-03 0:54 ` Andrew Morton
2003-06-03 1:00 ` Nick Piggin
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2003-06-03 0:54 UTC (permalink / raw)
To: Nick Piggin; +Cc: kernel, linux-kernel
Nick Piggin <piggin@cyberone.com.au> wrote:
>
> It will be interesting to see what happens if we set the
> ext3 journal write paths as PF_SYNCWRITE. I'll try some tests
> a bit later today.
>
OK.
Longer-term it would be best to lose the PF_SYNCWRITE thing and to just
mark the BIOs as synchronous prior to submitting them. It's a matter of
transferring the info in writeback_control.sync_mode at the pagecache/BIO
boundary: mpage_bio_submit(), __block_write_full_page->submit_bh(), etc.
But we can worry about that later, once it is established that the
synchronous write detection is sufficiently useful.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BENCHMARK] 2.5.70-mm2 with contest
2003-06-03 0:54 ` Andrew Morton
@ 2003-06-03 1:00 ` Nick Piggin
0 siblings, 0 replies; 6+ messages in thread
From: Nick Piggin @ 2003-06-03 1:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: kernel, linux-kernel
Andrew Morton wrote:
>Nick Piggin <piggin@cyberone.com.au> wrote:
>
>
>>It will be interesting to see what happens if we set the
>> ext3 journal write paths as PF_SYNCWRITE. I'll try some tests
>> a bit later today.
>>
>>
>>
>
>OK.
>
>Longer-term it would be best to lose the PF_SYNCWRITE thing and to just
>mark the BIOs as synchronous prior to submitting them. It's a matter of
>transferring the info in writeback_control.sync_mode at the pagecache/BIO
>boundary: mpage_bio_submit(), __block_write_full_page->submit_bh(), etc.
>
>
Yeah that is better. Would be no problem for AS.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-06-03 0:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-06-02 22:06 [BENCHMARK] 2.5.70-mm2 with contest Con Kolivas
2003-06-02 22:16 ` Andrew Morton
2003-06-03 0:30 ` Nick Piggin
2003-06-03 0:54 ` Andrew Morton
2003-06-03 1:00 ` Nick Piggin
2003-06-03 0:44 ` Pasi Savolainen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox