[lkml]   [2003]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: tbench as a load - DDOS attack?
Con Kolivas <> wrote:
> Zwane M suggested using tbench as a load to test one of his recent patches and
> gave me the idea to try using tbench_load in contest. Here are the first set
> of results I got while running tbench 4 continuously (uniprocessor machine):
> tbench_load:
> Kernel [runs] Time CPU%
> test2420 1 180 38.9
> test2561 1 970 7.7
> This is a massive difference. Sure tbench was giving better numbers on 2.5.61
> but it caused a massive slowdown. I wondered whether this translates into
> being more susceptible to ping floods or DDOS attacks? You should have seen
> tbench 16 - 3546 seconds!

Yes, something is wrong with the CPU scheduler. Simple test case:

./tbench_srv &
while true
./tbench 4
done &
cd /usr/src/util-linux
time make -j4

The tbench activity takes the time to compile util-linux from 13 second to
133 seconds.

But that is not the whole story. The compilation appeared to make no
progress at all while tbench was running - it was only in the gaps between
ending one tbench run and starting another that the compilation did anything.

When I changed the load to one instance of

while true
./tbench 2

and one instance of

while true
./tbench 3

the compilation made no progress except for those rare instances when the two
shell scripts were restarting the tbench run at the same time. After a while
the scripts fell itno synchronism, and the compilation took 260 seconds.

Conclusion: tbench completely starves the `make'.

It mainly seems to affect uniprocessor builds. SMP was much better behaved.

Adding the sched-f3 patch basicaly fixed it all up. The 133 second build
came down to 55 seconds, and the compilation was visibly making progress
during the tbench runs.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.032 / U:3.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site