Poor performance with 2.5.52, load and process in D state
Hi Andrew/Rik/Con/all
Andrew, I promised you to run a few tests using osdb (www.osdb.org with 40M of data)against both 2.4.19 and 2.5.52 booting the kernel with the mem=XXM paramter.
I also played with the /proc/sys/vm/swappiness parameter, I've ran all the tests with the standard swappiness value (60), with 80 and 100.
100 means the 2.4 behaviour, isn't it ?
Looking at the results it seems that the "standard" value is too low, probably 80 is the best one. What do you think ?
There is no a big difference in the Time results between 80 and 100 but looking at the top output while I was running the tests I saw a big difference in the swap usage.
Con, could you please run the contest test against 2.5.52 or .53 platying with the swappines parameter ?
Below the results of my test, please let me know if you want I run more tests or if you need more information.
Ciao,
Paolo
-- By Memory Size --
Kernel Memory Swappiness Time
2.4.19 24 x 3371.98 seconds (0:56:11.98)
2.5.52 24 60 4585.03 seconds (1:16:25.03)
2.5.52 24 80 4285.98 seconds (1:11:25.98)
2.5.52 24 100 3633.64 seconds (1:00:33.64)
2.4.19 40 x 809.39 seconds (0:13:29.39)
2.5.52 40 60 3771.85 seconds (1:02:51.85)
2.5.52 40 80 3342.82 seconds (0:55:42.82)
2.5.52 40 100 855.22 seconds (0:14:15.22)
2.4.19 64 x 796.03 seconds (0:13:16.03)
2.5.52 64 60 840.41 seconds (0:14:00.41)
2.5.52 64 80 828.59 seconds (0:13:48.59)
2.5.52 64 100 833.92 seconds (0:13:53.92)
2.4.19 80 x 790.80 seconds (0:13:10.80)
2.5.52 80 60 788.65 seconds (0:13:08.65)
2.5.52 80 80 790.54 seconds (0:13:10.54)
2.5.52 80 100 793.79 seconds (0:13:13.79)
2.5.52 96 60 779.54 seconds (0:12:59.54)
2.5.52 96 80 782.86 seconds (0:13:02.86)
2.5.52 96 100 778.81 seconds (0:12:58.81)
2.4.19 all x 778.65 seconds (0:12:58.65)
2.5.52 all 60 768.98 seconds (0:12:48.98)
2.5.52 all 80 770.43 seconds (0:12:50.43)
2.5.52 all 100 771.76 seconds (0:12:51.76)
-- By kernel version --
2.4.19 24 x 3371.98 seconds (0:56:11.98) 2.4.19 40 x 809.39 seconds (0:13:29.39) 2.4.19 64 x 796.03 seconds (0:13:16.03) 2.4.19 80 x 790.80 seconds (0:13:10.80) 2.4.19 all x 778.65 seconds (0:12:58.65)
2.5.52 24 60 4585.03 seconds (1:16:25.03) 2.5.52 40 60 3771.85 seconds (1:02:51.85) 2.5.52 64 60 840.41 seconds (0:14:00.41) 2.5.52 80 60 788.65 seconds (0:13:08.65) 2.5.52 96 60 779.54 seconds (0:12:59.54) 2.5.52 all 60 768.98 seconds (0:12:48.98)
2.5.52 24 80 4285.98 seconds (1:11:25.98) 2.5.52 40 80 3342.82 seconds (0:55:42.82) 2.5.52 64 80 828.59 seconds (0:13:48.59) 2.5.52 80 80 790.54 seconds (0:13:10.54)
2.5.52 96 80 782.86 seconds (0:13:02.86)
2.5.52 all 80 770.43 seconds (0:12:50.43)
2.5.52 24 100 3633.64 seconds (1:00:33.64) 2.5.52 40 100 855.22 seconds (0:14:15.22) 2.5.52 64 100 833.92 seconds (0:13:53.92) 2.5.52 80 100 793.79 seconds (0:13:13.79) 2.5.52 96 100 778.81 seconds (0:12:58.81) 2.5.52 all 100 771.76 seconds (0:12:51.76)
Signature · 5 lines
______________________________________________ http://www.linuxmail.org/ Now with POP3/IMAP access for only US$19.95/yr Powered by Outblaze
Quoted 8 lines · Paolo Ciarrocchi
Hi Andrew/Rik/Con/all
Andrew, I promised you to run a few tests using osdb (www.osdb.org with 40M of data)against both 2.4.19 and 2.5.52 booting the kernel with the mem=XXM paramter.
Quoted 5 lines
I also played with the
/proc/sys/vm/swappinessparameter, I've ran all the tests with the standard swappiness value (60), with 80 and 100.100 means the 2.4 behaviour, isn't it ?
Not really. swappiness=100 is strict LRU, treating pagecache and mapped-into-process-memory pages identically. Smaller values will make the kernel prefer to preserve mapped-into-process-memory.
Quoted 3 lines
Looking at the results it seems that the "standard" value is too low, probably 80 is the best one. What do you think ?
I would agree with that.
Quoted 6 lines
...
2.4.19 all x 778.65 seconds (0:12:58.65) 2.5.52 all 60 768.98 seconds (0:12:48.98) 2.5.52 all 80 770.43 seconds (0:12:50.43) 2.5.52 all 100 771.76 seconds (0:12:51.76)
Only 1% difference. On my 4xPIII with mem=128M, 2.4.20-pre2 took 1080.55 seconds and 2.5.52-mm3 took 991.03. That's 9% faster, and from the profile:
c010a858 system_call 192 4.3636 c011e518 current_kernel_time 201 3.3500 c012cdbc __generic_file_aio_read 214 0.4652 c012bba0 kallsyms_lookup 219 0.8295 c012ccec file_read_actor 230 1.1058 c0145abc fget 318 4.1842 c01d3ed4 radix_tree_lookup 384 3.8400 c0144be0 vfs_read 409 1.3279 c01315f4 check_poison_obj 695 7.8977 c012c964 do_generic_mapping_read 1007 1.1988
c01d7ae0 __copy_user_intel 34130 213.3125c0108a58 poll_idle 299231 3562.2738
it appears that this benefit came from the special usercopy code. What sort of CPU are you using?