Thanks very much for your explanation
At the very beginning I thought the Hackbench was a latency tools, so I was very surprised to see such result.
But there's another question. When I choose the Complete Preemption -Real Time configuration, it's recommended to choose Timer Frequency ---> 1000Mhz to improve the cpu performance, does it mean cpu will cost much more during the thread context switch? Or I should choose 100Mhz in order to decrease the thread context switch and get a better performance?
Which one should I choose? Or any useful tools can tell me the differences.
Any opinion appreciated
Thanks
Really Thanks again
-----Original Message-----
From: Steven Rostedt [mailto:rostedt@goodmis.org]
Sent: 2008年5月20日 12:37
To: MA QING A
Cc: Kasper Sandberg; LKML; RT; Ingo Molnar; Thomas Gleixner
Subject: RE: 2.6.25.4-rt2
On Tue, 20 May 2008, MA QING A wrote:
The test I used is a performance test, not a latency test. An RTOS
(Real-time Operating System) will sacrifice performance to achieve
determinism (low latencies). Several key features to an RT system usually
come with a performance cost.
A non RT system will perform 99% of the time faster than an RTOS. But all
it takes is that one time to miss a deadline to make an RT system crash.
An RTOS may be slightly slower, but it will not have those outliers that a
normal desktop system would have.
So getting back to your question. Hackbench runs a bunch of stuff and
times how long it took to do so. It stresses the system quite a bit. The
lower the number the better. Given that hackbench is not checking for
latency, but only shear perforance, it is expected that hackbench will run
better on a non RT system.
Now, a test like cyclictest that measures latencies will show the benefits
of realtime. The kernel with the RT patch can measure 65 microsecond
latencies for response times even while running hackbench. The vanilla
kernel would measure a few milliseconds response times running the same
test.
-- Steve
--
