Timer utility function to use single timer


Bag, Amit K <amit.k.bag@...>
 

Hi All,

In Zephyr there will be a chance to run out of timers at times and we will not get the timer handle to use for our modules.
Means whenever we required a timer for our module we can call a timer API defined in zephyr (i.e. task_timer_alloc(),task_timer_start(),task_timer_stop, etc )
or we need to have a pool of timer handle at the time of initialization so that we can use one of them from the pool when we need it.
Is there such a utility function already available. In case of multiple task are calling timer function and the OS is running out of timer to satisfy all the timer calls how this is handled in Zephyr OS.



Thanks & Regards,
Amit Bag


Andy Ross
 

Bag, Amit K wrote:
In Zephyr there will be a chance to run out of timers at times and
we will not get the timer handle to use for our modules.

Means whenever we required a timer for our module we can call a
timer API defined in zephyr
(i.e. *task_timer_alloc(),task_timer_start(),task_timer_stop, etc*)
I'm a little curious about this API design too. AFAICT, it's always
legal to statically allocate a k_timer struct of your own and
initialize and use it at runtime. If you need to know you won't run
out of timers, you can be guaranteed not to lose this one.

The allocate/free API looks like it's just a convenience wrapper to
allow sharing of timer objects between usages if you know they aren't
all going to be needed simultaneously.

The problem though, is that to get this facility Zephyr allocates 10
(by default) k_timer objects in a pool and shares only those.
Obviously Zephyr has no heap, so it can't share the memory as anything
but timers. And these aren't tiny objects. My quick manual count
says that they're 64 bytes a piece, so that's half a kb of RAM that
we're allocating in every default-configured app just to save a
handful of bytes in apps that want to use the "sharing" convenience
API. That seems like a bad trade to me.

Would anyone object to a patch that set CONFIG_NUM_DYNAMIC_TIMERS to
zero by default and disabled the API unless it was 1 or greater? Or
maybe deprecating it for future removal?

Andy


Dmitriy Korovkin
 

On Fri, 23 Sep 2016, Andy Ross wrote:

Bag, Amit K wrote:
In Zephyr there will be a chance to run out of timers at times and
we will not get the timer handle to use for our modules.

Means whenever we required a timer for our module we can call a
timer API defined in zephyr
(i.e. *task_timer_alloc(),task_timer_start(),task_timer_stop, etc*)
I'm a little curious about this API design too. AFAICT, it's always
legal to statically allocate a k_timer struct of your own and
initialize and use it at runtime. If you need to know you won't run
out of timers, you can be guaranteed not to lose this one.

The allocate/free API looks like it's just a convenience wrapper to
allow sharing of timer objects between usages if you know they aren't
all going to be needed simultaneously.

The problem though, is that to get this facility Zephyr allocates 10
(by default) k_timer objects in a pool and shares only those.
Obviously Zephyr has no heap, so it can't share the memory as anything
but timers. And these aren't tiny objects. My quick manual count
says that they're 64 bytes a piece, so that's half a kb of RAM that
we're allocating in every default-configured app just to save a
handful of bytes in apps that want to use the "sharing" convenience
API. That seems like a bad trade to me.

Would anyone object to a patch that set CONFIG_NUM_DYNAMIC_TIMERS to
zero by default and disabled the API unless it was 1 or greater? Or
maybe deprecating it for future removal?
I was also thinking on setting this to 0 and save some space.
/Dmitriy

Andy


Andy Ross
 

Korovkin, Dmitriy wrote:
On Fri, 23 Sep 2016, Andy Ross wrote:
Would anyone object to a patch that set CONFIG_NUM_DYNAMIC_TIMERS to
zero by default and disabled the API unless it was 1 or greater? Or
maybe deprecating it for future removal?
I was also thinking on setting this to 0 and save some space.
/Dmitriy
https://gerrit.zephyrproject.org/r/#/c/4954/


Boie, Andrew P
 

On Fri, 2016-09-23 at 09:41 -0700, Andy Ross wrote:
Would anyone object to a patch that set CONFIG_NUM_DYNAMIC_TIMERS to
zero by default and disabled the API unless it was 1 or greater?  Or
maybe deprecating it for future removal?
+1 on deprecation!

Andrew


Bag, Amit K <amit.k.bag@...>
 

Hi Ross,

As you mentioned it's always legal to statically allocate a k_timer struct of your own and initialize and use it at runtime. But suppose we allocated 10 timer structure and now if we make another call to initialize 1 more timer structure it will fail. How to handle that issue. If more than 10 timers are required in a module then statically we cannot allocate more than 10 timer in a given time. Is there any implementation or patch available to have only 1 timer structure initialized in the beginning and simulate all the other timer request coming from above and satisfy them by maintaining only 1 timer internally without actually requesting more timer to the zephyr OS. This will reduce the timer request to zephyr OS and will not have the risk of running out of the timers.


Thanks & Regards,
Amit Bag

-----Original Message-----
From: Ross, Andrew J
Sent: Friday, September 23, 2016 10:11 PM
To: Bag, Amit K <amit.k.bag(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Timer utility function to use single timer

Bag, Amit K wrote:
In Zephyr there will be a chance to run out of timers at times and we
will not get the timer handle to use for our modules.

Means whenever we required a timer for our module we can call a timer
API defined in zephyr (i.e.
*task_timer_alloc(),task_timer_start(),task_timer_stop, etc*)
I'm a little curious about this API design too. AFAICT, it's always legal to statically allocate a k_timer struct of your own and initialize and use it at runtime. If you need to know you won't run out of timers, you can be guaranteed not to lose this one.

The allocate/free API looks like it's just a convenience wrapper to allow sharing of timer objects between usages if you know they aren't all going to be needed simultaneously.

The problem though, is that to get this facility Zephyr allocates 10 (by default) k_timer objects in a pool and shares only those.
Obviously Zephyr has no heap, so it can't share the memory as anything but timers. And these aren't tiny objects. My quick manual count says that they're 64 bytes a piece, so that's half a kb of RAM that we're allocating in every default-configured app just to save a handful of bytes in apps that want to use the "sharing" convenience API. That seems like a bad trade to me.

Would anyone object to a patch that set CONFIG_NUM_DYNAMIC_TIMERS to zero by default and disabled the API unless it was 1 or greater? Or maybe deprecating it for future removal?

Andy


Benjamin Walsh <benjamin.walsh@...>
 

In Zephyr there will be a chance to run out of timers at times and
we will not get the timer handle to use for our modules.

Means whenever we required a timer for our module we can call a
timer API defined in zephyr (i.e.
*task_timer_alloc(),task_timer_start(),task_timer_stop, etc*)
I'm a little curious about this API design too. AFAICT, it's always
legal to statically allocate a k_timer struct of your own and
initialize and use it at runtime. If you need to know you won't run
out of timers, you can be guaranteed not to lose this one.

The allocate/free API looks like it's just a convenience wrapper to
allow sharing of timer objects between usages if you know they
aren't all going to be needed simultaneously.
The main reason we still have k_timer_alloc and k_timer_free is to
support the legacy APIs task_timer_alloc and task_timer_free.

How about making the allocation/freeing of timers hidden, and only there
to support the legacy API ? The paradigm for the unified kernel would
then be "use statically allocated timers".

As you mentioned it's always legal to statically allocate a k_timer
struct of your own and initialize and use it at runtime. But suppose
we allocated 10 timer structure and now if we make another call to
initialize 1 more timer structure it will fail. How to handle that
issue. If more than 10 timers are required in a module then statically
we cannot allocate more than 10 timer in a given time. Is there any
implementation or patch available to have only 1 timer structure
initialized in the beginning and simulate all the other timer request
coming from above and satisfy them by maintaining only 1 timer
internally without actually requesting more timer to the zephyr OS.
This will reduce the timer request to zephyr OS and will not have the
risk of running out of the timers.

The problem though, is that to get this facility Zephyr allocates 10
(by default) k_timer objects in a pool and shares only those.
Obviously Zephyr has no heap, so it can't share the memory as
anything but timers. And these aren't tiny objects. My quick
manual count says that they're 64 bytes a piece, so that's half a kb
of RAM that we're allocating in every default-configured app just to
save a handful of bytes in apps that want to use the "sharing"
convenience API. That seems like a bad trade to me.

Would anyone object to a patch that set CONFIG_NUM_DYNAMIC_TIMERS to
zero by default and disabled the API unless it was 1 or greater? Or
maybe deprecating it for future removal?