On Tue, 27 Jun 2000, Pawan Singh wrote:
> 1. The piece of code I am running is a user process.
> 2. Only reason I tried CLI() and STI() is so that I can find out how much
> time does the CPU take to execute the code - just as a benchmark. I will
> never use cli and sti in the user land.
>
> 3. I finally have one more clue. It does not matter if it is a floating
> point operation inside the loop. One gets the same results with integer
> operations. The result gets worse and worse depending on the number of
> instructions in the loop.
>
> 4. I have made sure that compiler has not optimized anything. The piece of
> code I typed was just a quick demonstration. Add to the code something after
> the loop (like printf) which uses the sum total being produced by the loop.
>
> So in short it seems to me is this - for one integer add:
> 1. Interrupts turned off: 1000000 integer additions take 10ms.
> 2. With interrupts turned on 10000000 integer additions take 270ms.
>
> To me it is 27 times kernel overhead.
>
> If I increase the number of integer instructions in the loop to what
> floating point code does for two float additions i.e. 100 instructions,
> 1. Interrupts turned off: 10000 loop interations take 10ms.
> 2. With interrupts turned on 100000 loop iterations take 1000 to 2000
> seconds.
>
> To me in this case it is 100-200 times kernel overhead.
>
> These numbers can be reproduced on any 486, 386 with 8K L1 cache.
>
> Comments?
How do you measure the elapsed time?
Since time counters in the kernel are 10 ms precision and incremented at
each timer interrupt, you just don't have the real elapsed time when IRQs
are masqued.
Nicolas
--
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the command "unsubscribe linux-embedded" in the message body.
For more information, see <http://waste.org/mail/linux-embedded>.
