I don't known where to post it exactly. Why Linux Memory Management? Or why -mm and not mainstream? Can you do it for me please?
I have added a second test case, which using threads with pthread_mutex and pthread_cond instead of processes with pipes for communicating, to ensure it is a cpu scheduler issue.
I have repeated the tests with some vanilla kernels again, as there is a remark in the bug report for tainted or distro kernels. As I got a segmentation fault with the 2.6.28 kernel, I added the result of the Ubuntu 9.04 kernel (see attachment). The results are not comparable to the results posted before, as I have changed the time handling (doubles instead of int32_t as some echo messages takes more than one second).
The first three results are 2*100, 2*50 and 2*20 processes exchanging 100k, 200k and 1M messages over a pipe. The last three results are 2*100, 2*50, and 2*20 threads exchanging 100k, 200k and 1M messages with pthread_mutex and pthread_cond. I have added a 10 second pause at the beginning of every thread/process to assure the 2*100 processes or threads are all created and start to exchange the messages nearby at the same time. This was not the case at the old test-case with 2*100 processes, as the first thread was already destroyed before the last was created.
With the second test-case with threads, I got the problems (threads:2*100/msg:1M) immediately with the kernel 2.6.22.19. There kernel 2.6.20.21 was fine with both test-cases.
The meaning of the results:
- min message time
- average message time (80% of the messages)
- message time at median
- maximal message time
- test duration
Here the result.
Linux balrog704 2.6.20.21 #1 SMP Wed Jan 14 10:11:34 CET 2009 x86_64 GNU/Linux
min:0.000ms|avg:0.241-0.249ms|mid:0.244ms|max:18.367ms|duration:25.304s
min:0.002ms|avg:0.088-0.094ms|mid:0.093ms|max:17.845ms|duration:19.694s
min:0.002ms|avg:0.030-0.038ms|mid:0.038ms|max:564.062ms|duration:38.370s
min:0.002ms|avg:0.004-0.007ms|mid:0.004ms|max:1212.746ms|duration:33.137s
min:0.002ms|avg:0.004-0.005ms|mid:0.004ms|max:1092.045ms|duration:31.686s
min:0.002ms|avg:0.004-0.007ms|mid:0.004ms|max:4532.159ms|duration:59.773s
Linux balrog704 2.6.22.19 #1 SMP Wed Jan 14 10:16:43 CET 2009 x86_64 GNU/Linux
min:0.003ms|avg:0.394-0.413ms|mid:0.403ms|max:19.673ms|duration:42.422s
min:0.003ms|avg:0.083-0.188ms|mid:0.182ms|max:13.405ms|duration:37.038s
min:0.003ms|avg:0.056-0.075ms|mid:0.070ms|max:656.112ms|duration:72.943s
min:0.003ms|avg:0.005-0.010ms|mid:0.007ms|max:1756.113ms|duration:49.163s
min:0.003ms|avg:0.005-0.010ms|mid:0.007ms|max:11560.976ms|duration:52.836s
min:0.003ms|avg:0.008-0.010ms|mid:0.010ms|max:5316.424ms|duration:111.323s
Linux balrog704 2.6.24.7 #1 SMP Wed Jan 14 10:21:04 CET 2009 x86_64 GNU/Linux
min:0.003ms|avg:0.223-0.450ms|mid:0.428ms|max:8.494ms|duration:46.123s
min:0.003ms|avg:0.140-0.209ms|mid:0.200ms|max:12.514ms|duration:39.100s
min:0.003ms|avg:0.068-0.084ms|mid:0.076ms|max:38.778ms|duration:78.157s
min:0.003ms|avg:0.454-0.784ms|mid:0.625ms|max:11.063ms|duration:65.619s
min:0.004ms|avg:0.244-0.399ms|mid:0.319ms|max:21.018ms|duration:64.741s
min:0.003ms|avg:0.061-0.138ms|mid:0.111ms|max:23.861ms|duration:126.309s
Hello Ben,
I don't known where to post it exactly. Why Linux Memory Management? Or why -mm and not mainstream? Can you do it for me please?
I have added a second test case, which using threads with pthread_mutex and pthread_cond instead of processes with pipes for communicating, to ensure it is a cpu scheduler issue.
I have repeated the tests with some vanilla kernels again, as there is a remark in the bug report for tainted or distro kernels. As I got a segmentation fault with the 2.6.28 kernel, I added the result of the Ubuntu 9.04 kernel (see attachment). The results are not comparable to the results posted before, as I have changed the time handling (doubles instead of int32_t as some echo messages takes more than one second).
The first three results are 2*100, 2*50 and 2*20 processes exchanging 100k, 200k and 1M messages over a pipe. The last three results are 2*100, 2*50, and 2*20 threads exchanging 100k, 200k and 1M messages with pthread_mutex and pthread_cond. I have added a 10 second pause at the beginning of every thread/process to assure the 2*100 processes or threads are all created and start to exchange the messages nearby at the same time. This was not the case at the old test-case with 2*100 processes, as the first thread was already destroyed before the last was created.
With the second test-case with threads, I got the problems (threads: 2*100/msg: 1M) immediately with the kernel 2.6.22.19. There kernel 2.6.20.21 was fine with both test-cases.
The meaning of the results:
- min message time
- average message time (80% of the messages)
- message time at median
- maximal message time
- test duration
Here the result. avg:0.241- 0.249ms| mid:0.244ms| max:18. 367ms|duration: 25.304s avg:0.088- 0.094ms| mid:0.093ms| max:17. 845ms|duration: 19.694s avg:0.030- 0.038ms| mid:0.038ms| max:564. 062ms|duration: 38.370s avg:0.004- 0.007ms| mid:0.004ms| max:1212. 746ms|duration: 33.137s avg:0.004- 0.005ms| mid:0.004ms| max:1092. 045ms|duration: 31.686s avg:0.004- 0.007ms| mid:0.004ms| max:4532. 159ms|duration: 59.773s
Linux balrog704 2.6.20.21 #1 SMP Wed Jan 14 10:11:34 CET 2009 x86_64 GNU/Linux
min:0.000ms|
min:0.002ms|
min:0.002ms|
min:0.002ms|
min:0.002ms|
min:0.002ms|
Linux balrog704 2.6.22.19 #1 SMP Wed Jan 14 10:16:43 CET 2009 x86_64 GNU/Linux avg:0.394- 0.413ms| mid:0.403ms| max:19. 673ms|duration: 42.422s avg:0.083- 0.188ms| mid:0.182ms| max:13. 405ms|duration: 37.038s avg:0.056- 0.075ms| mid:0.070ms| max:656. 112ms|duration: 72.943s avg:0.005- 0.010ms| mid:0.007ms| max:1756. 113ms|duration: 49.163s avg:0.005- 0.010ms| mid:0.007ms| max:11560. 976ms|duration: 52.836s avg:0.008- 0.010ms| mid:0.010ms| max:5316. 424ms|duration: 111.323s
min:0.003ms|
min:0.003ms|
min:0.003ms|
min:0.003ms|
min:0.003ms|
min:0.003ms|
Linux balrog704 2.6.24.7 #1 SMP Wed Jan 14 10:21:04 CET 2009 x86_64 GNU/Linux avg:0.223- 0.450ms| mid:0.428ms| max:8.494ms| duration: 46.123s avg:0.140- 0.209ms| mid:0.200ms| max:12. 514ms|duration: 39.100s avg:0.068- 0.084ms| mid:0.076ms| max:38. 778ms|duration: 78.157s avg:0.454- 0.784ms| mid:0.625ms| max:11. 063ms|duration: 65.619s avg:0.244- 0.399ms| mid:0.319ms| max:21. 018ms|duration: 64.741s avg:0.061- 0.138ms| mid:0.111ms| max:23. 861ms|duration: 126.309s
min:0.003ms|
min:0.003ms|
min:0.003ms|
min:0.003ms|
min:0.004ms|
min:0.003ms|