how big is the timer event overhead?

how big is the timer event overhead?

[Michael Zimmermann]

Hi,

if I add a timer with an interval of 1ms, how much will it affect the
system performance?
The callback only adds +1 to a global variable so I can keep track of the
total uptime without the need of a RTC.

Thanks
Michael

Re: how big is the timer event overhead?

[Andrew Fish]

> On Sep 17, 2016, at 8:13 AM, Michael Zimmermann <sigmaepsilon92@gmail.com> wrote:
> 
> Hi,
> 
> if I add a timer with an interval of 1ms, how much will it affect the
> system performance?
> The callback only adds +1 to a global variable so I can keep track of the
> total uptime without the need of a RTC.
> 

Michael,

In general the EFI Contract is you get at least the delay you asked for, but the quality of service is not guaranteed. The PI spec abstracts the system timer for the DXE Core via the Timer Architectural Protocol, https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/Timer.h. The timers you request in EFI are software timers that are implemented using the Timer Protocol, but you are only going to get the quality of service of the Timer Period set by the Timer Protocol implementation (platform). You can query the period by calling GetTimerPeriod(). 

1st rule of performance tuning is to never assume how stuff works and always measure, that caveat aside here is conceptually what is going on.....

EFI has an event driven model and it is cooperative (you could also argue it is a run to completion model) in that event functions exit to give control to other events. Events at equal to or less than TPL are blocked from running when an event is running at a given TPL (that is the run to completion bit). The cooperative bit is there is no scheduler, and there is only one thread and thus a common stack for the driver/application that is running and all the events. There is basically a queue, per TPL, of all the events that have been registered. This event queue is processed on calls to gBS->RestoreTPL() and any event that is a higher TPL than the restore can get called. Given the Timer tick is an interrupt it will raise to TPL_HIGH_LEVEL and then restore the TPL. This restoring of the TPL is what causes events to happen. 

So to  answer your question it kind of depends on your timer period and how many events you have as that is the time that is being stolen away from the driver/application that is running.  


If you are trying to measure elapsed time using a timer event is probably not a good way to do that since there is no scheduler the quality of service is not that good (the time between ticks will be no shorter than requested but could be longer). If your code is independent of the platform the Timestamp protocol may be useful for what you are doing https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/Timestamp.h. Note it is newish so may not be on every platform. 

For code in the ROM that knows about the platform the TimerLib, https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/TimerLib.h, is used for getting timing information. The combination of GetPerfomanceCounter(), GetPerfomanceCounterProperties(), and GetTimeInNanoSecond() can be used to do what you want I think. Generally on an X86 system this is the TSC, but figuring out the period of the TSC can be tricky if you don't know about your platform.

Thanks,

Andrew Fish

> Thanks
> Michael
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel