Re: how to calculate time required for the execution of the entry point of the driver ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

On 14:40 Fri 28 Nov     , yogeshwar sonawane wrote:
> Hi all,
> 
> 1) I have a driver code providing ioctl,read, write, mmap etc. entry points.
> Now, i want to find the execution time of each entry point for comparison.
>
> How this can be done ?
> for ex.
> 
> take time_stamp1
> call entry point
> take time_stamp2
> 
> The above code from a user application can measure the execution time
> ?  Timing functions in user space are close to the real time ?
> 
> 
> 2) Which timing functions should be used to get the, close to correct
> time, in user & kernel space ?
> Mainly the purpose is to calculate timing interval.


I would call the syscalls multiple times. This way, there is no requirement for
a ultra high resolution clock. gettimeofday() will probably be enough. But 
there are some other pitfalls:

- The time the ioctl, ... takes depends on whether the required things are
already cached in the CPU cache or not. If you want to measure how long it
takes with a cold cache, you can try to trash it between runs. But then you
cannot easily call gettimeofday() before and after a loop of the ioctl(). You
can call gettimeofday(), ioctl(), gettimeofday(), trash the cpu cache, then
do it again. But
- gettimeofday() itself takes some time. This means even if the resolution is
high enough or if you average of a lot samples, this time always adds to the
result. If you trash the CPU cache, you may also alter the time gettimeofday()
takes. You may want to offset this by calling a gettimeofday() and ignoging the
result to get the data into the cache. You can also try to offset the
gettimeofday() times by measuring the time gettimeofday() takes and
substracting this of the result.
- Do not run any other process to make sure that the benchmark process does get
the cpu.
- Something else may come up.
	-Michi
-- 
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com


--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux