This is how you implement timers in HW as well. A separate HW block operates a scan loop that constantly searches for timers to expire and creates events for those who do. The rest of the system operates undisturbed. For a SW analog in manycore systems you'd have service thread(s) running on dedicated core(s) doing the same.
On Thu, Jan 28, 2016 at 12:41 PM, Stuart Haslam <[email protected]> wrote: > On Thu, Jan 28, 2016 at 09:31:52PM +0300, Maxim Uvarov wrote: > > I have some thoughts and questions about timer implementation in > > linux-generic. > > > > Current implementation: > > > > sigev.sigev_notify = SIGEV_THREAD; > > sigev.sigev_notify_function = timer_notify; > > sigev.sigev_value.sival_ptr = tp; > > timer_create(CLOCK_MONOTONIC, &sigev, &tp->timerid); > > then: > > timer_settime(tp->timerid, 0, &ispec, NULL); > > > > where: > > timer_notify(sigval_t sigval) > > { > > uint64_t prev_tick = odp_atomic_fetch_inc_u64(&tp->cur_tick); > > /* Attempt to acquire the lock, check if the old value was clear */ > > if (odp_spinlock_trylock(&tp->itimer_running)) { > > /* Scan timer array, looking for timers to expire */ > > (void)odp_timer_pool_expire(tp, prev_tick); > > odp_spinlock_unlock(&tp->itimer_running); > > } > > > > } > > > > Now what I see from our test case. > > 1. We have bunch of workers. > > 2. Each worker starts timer. > > 3. Because it's SIGEV_THREAD on timer action new thread for notifier > > function started. > > > > Usually it works well. Until there is load on cpu. (something like > > busy loop app.) There a lot of threads > > just created by kernel. I.e. execution clone() call. > > > > Based that I have question I have questions which is not quite clear for > me: > > 1. Why SIGEV_THREAD was used? > > > > 2. When each worker will run bunch of threads (timer handler), they > > will fight for cpu time for context > > switches between all that threads. Is there significant slowdown > > compare to one thread or signal usage? > > > > 3. What is priority of timer handler against to worker? Cpu affinity > > of handler thread? Should it > > be SHED_FIFO? I.e. do we need to specify that thread attrs? > > > > I think that creation thread each time only for increasing atomic > > counter is very expensive. So we can > > rewrite that code to use SIGEV_SIGNAL or start thread manually and > > SIGEV_THREAD_ID + semaphore. > > > > If we will think about core isolation, than probably we have to work > > with signals. Don't know if core isolation > > supports several threads on one core. Or even move all timer actions > > to separate core to not disturb worker > > cores. > > > > Thank you, > > Maxim. > > +1 > > This is basically what was suggested here: > > https://bugs.linaro.org/show_bug.cgi?id=1615#c18 > > -- > Stuart. > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
