Bug in recent kernel timer implementation

Hi, Seems like kernel timer implementation is buggy since some kernel version (between 3.16.0 and 4.9.0). Comments for add_timer in timer.c: * The kernel will do a ->function(@timer) callback from the  * timer interrupt at the ->expires point in the future. The  * current time is &#

query on linux kernel timer implementation

Hi Team, We have a query on the implementation linux timer implementation. We have been running our application on linux kernel 4.9.168 (debian - stretch) version. We use intel Rangeley 4 cpu system which has tsc timer. Our application is an multi-threaded program which creates a monotonic timer

[PATCHv7 03/11] ARM: smp: Remove duplicate dummy timer implementation

Drop ARM's version of the dummy timer now that we have a generic implementation in drivers/clocksource. Acked-by: Marc Zyngier , Cc: Russell King Signed-off-by: Stephen Boyd --- arch/arm/kernel/smp.c | 22 ++ 1 file changed, 2 insertions(+), 20 deletions(-) diff --git a/arc

Re: [PATCHv6 03/11] ARM: smp: Remove duplicate dummy timer implementation

On 05/13/13 12:26, Stephen Boyd wrote: > Drop ARM's version of the dummy timer now that we have a generic > implementation in drivers/clocksource. > > Cc: Russell King > Signed-off-by: Stephen Boyd Russell, can you please ack this patch and patch #11? > --- > arch/arm/kernel/smp.c | 22 ++-

[PATCHv6 03/11] ARM: smp: Remove duplicate dummy timer implementation

Drop ARM's version of the dummy timer now that we have a generic implementation in drivers/clocksource. Cc: Russell King Signed-off-by: Stephen Boyd --- arch/arm/kernel/smp.c | 22 ++ 1 file changed, 2 insertions(+), 20 deletions(-) diff --git a/arch/arm/kernel/smp.c b/arch

[PATCHv5 03/11] ARM: smp: Remove duplicate dummy timer implementation

Drop ARM's version of the dummy timer now that we have a generic implementation in drivers/clocksource. Cc: Russell King Signed-off-by: Stephen Boyd --- arch/arm/kernel/smp.c | 22 ++ 1 file changed, 2 insertions(+), 20 deletions(-) diff --git a/arch/arm/kernel/smp.c b/arch

[PATCHv4 03/11] ARM: smp: Remove duplicate dummy timer implementation

Drop ARM's version of the dummy timer now that we have a generic implementation in drivers/clocksource. Cc: Russell King Signed-off-by: Stephen Boyd --- arch/arm/kernel/smp.c | 22 ++ 1 file changed, 2 insertions(+), 20 deletions(-) diff --git a/arch/arm/kernel/smp.c b/arch

[PATCHv3 02/10] ARM: smp: Remove duplicate dummy timer implementation

Drop ARM's version of the dummy timer now that we have a generic implementation in drivers/clocksource. Cc: Russell King Signed-off-by: Stephen Boyd --- arch/arm/kernel/smp.c | 22 ++ 1 file changed, 2 insertions(+), 20 deletions(-) diff --git a/arch/arm/kernel/smp.c b/arch

[PATCH 02/10] ARM: smp: Remove duplicate dummy timer implementation

Drop ARM's version of the dummy timer now that we have a generic implementation in drivers/clocksource. Cc: Russell King Signed-off-by: Stephen Boyd --- arch/arm/kernel/smp.c | 22 ++ 1 file changed, 2 insertions(+), 20 deletions(-) diff --git a/arch/arm/kernel/smp.c b/arch

timer implementation

dear sir i want to implement a timer inside the kernel so that a specific function of mine is called after certain period of time how to implement that? thanks in advance sounak Yahoo! India Matrimony: Find your partn

Re: [patch] new, scalable timer implementation, smptimers-2.4.0-B1

On Wed, 31 Jan 2001, Daniel Phillips wrote: > b) The current API looks like it was designed primarly with one-shot > timers in mind. Most timers events are multishot (because > sleep_on_timeout is better for most one-shot applications [...] sleep_on_timeout() uses a one-shot timer internally

Re: [patch] new, scalable timer implementation, smptimers-2.4.0-B1

s > implementation is a work of David Miller, Alexey Kuznetsov and myself. > > Internals: the current 2.4 timer implementation uses a global spinlock for > synchronizing access to the global timer lists. This causes excessive > cacheline ping-pongs and visible performance degradat

[patch] new, scalable timer implementation, smptimers-2.4.0-B1

netsov and myself. Internals: the current 2.4 timer implementation uses a global spinlock for synchronizing access to the global timer lists. This causes excessive cacheline ping-pongs and visible performance degradation under very high TCP networking load (and other, timer-intensive operations)