28 Jun, 2011
1 commit
-
Fix 'make htmldocs' warnings:
Warning(/include/linux/hrtimer.h:153): No description found for parameter 'clockid'
Warning(/include/linux/device.h:604): Excess struct/union/enum/typedef member 'of_match' description in 'device'
Warning(/include/net/sock.h:349): Excess struct/union/enum/typedef member 'sk_rmem_alloc' description in 'sock'Signed-off-by: Vitaliy Ivanov
Acked-by: Grant Likely
Acked-by: David S. Miller
Signed-off-by: Linus Torvalds
23 May, 2011
4 commits
-
The ordering of the clock bases is historical due to the
CLOCK_REALTIME and CLOCK_MONOTONIC constants. Now the hrtimer bases
have their own enumeration due to the gap between CLOCK_MONOTONIC and
CLOCK_BOOTTIME. So we can be more clever as most timers end up on the
CLOCK_MONOTONIC base due to the virtue of POSIX declaring that
relative CLOCK_REALTIME timers are not affected by time changes. In
desktop environments this is slowly changing as applications switch to
absolute timers, but I've observed empty CLOCK_REALTIME bases often
enough. There is no performance penalty or overhead when
CLOCK_REALTIME timers are active, but in case they are not we don't
skip over a full cache line.Signed-off-by: Thomas Gleixner
Reviewed-by: Peter Zijlstra -
Instead of iterating over all possible timer bases avoid it by marking
the active bases in the cpu base.Signed-off-by: Thomas Gleixner
Reviewed-by: Peter Zijlstra -
In the HIGHRES=y case we access the members at the end of struct
hrtimer_cpu_base first and then the one at the beginning. Move the
hrtimer data to front, so we have linear progressing access.Signed-off-by: Thomas Gleixner
Reviewed-by: Peter Zijlstra -
Peter is concerned about the extra scan of CLOCK_REALTIME_COS in the
timer interrupt. Yes, I did not think about it, because the solution
was so elegant. I didn't like the extra list in timerfd when it was
proposed some time ago, but with a rcu based list the list walk it's
less horrible than the original global lock, which was held over the
list iteration.Requested-by: Peter Zijlstra
Signed-off-by: Thomas Gleixner
Reviewed-by: Peter Zijlstra
03 May, 2011
2 commits
-
Some applications must be aware of clock realtime being set
backward. A simple example is a clock applet which arms a timer for
the next minute display. If clock realtime is set backward then the
applet displays a stale time for the amount of time which the clock
was set backwards. Due to that applications poll the time because we
don't have an interface.Extend the timerfd interface by adding a flag which puts the timer
onto a different internal realtime clock. All timers on this clock are
expired whenever the clock was set.The timerfd core records the monotonic offset when the timer is
created. When the timer is armed, then the current offset is compared
to the previous recorded offset. When it has changed, then
timerfd_settime returns -ECANCELED. When a timer is read the offset is
compared and if it changed -ECANCELED returned to user space. Periodic
timers are not rearmed in the cancelation case.Signed-off-by: Thomas Gleixner
Acked-by: John Stultz
Cc: Chris Friesen
Tested-by: Kay Sievers
Cc: "Kirill A. Shutemov"
Cc: Peter Zijlstra
Cc: Davide Libenzi
Reviewed-by: Alexander Shishkin
Link: http://lkml.kernel.org/r/%3Calpine.LFD.2.02.1104271359580.3323%40ionos%3E
Signed-off-by: Thomas Gleixner -
Make clock_was_set() unconditional and rename hres_timers_resume to
hrtimers_resume. This is a preparatory patch for hrtimers which are
cancelled when clock realtime was set.Signed-off-by: Thomas Gleixner
11 Mar, 2011
1 commit
-
We changed some of the state bits and combinations thereof over time,
but never updated the documentation.Signed-off-by: Thomas Gleixner
22 Feb, 2011
3 commits
-
CLOCK_MONOTONIC stops while the system is in suspend. This is because
to applications system suspend is invisible. However, there is a
growing set of applications that are wanting to be suspend-aware,
but do not want to deal with the complications of CLOCK_REALTIME
(which might jump around if settimeofday is called).For these applications, I propose a new clockid: CLOCK_BOOTTIME.
CLOCK_BOOTTIME is idential to CLOCK_MONOTONIC, except it also
includes any time spent in suspend.This patch add hrtimer base for CLOCK_BOOTTIME, using
get_monotonic_boottime/ktime_get_boottime, to allow
in kernel users to set timers against.CC: Jamie Lokier
CC: Thomas Gleixner
CC: Alexander Shishkin
CC: Arve Hjønnevåg
Signed-off-by: John Stultz -
This adds new functions that return the monotonic time since boot
(in other words, CLOCK_MONOTONIC + suspend time).CC: Jamie Lokier
CC: Thomas Gleixner
CC: Alexander Shishkin
CC: Arve Hjønnevåg
Signed-off-by: John Stultz -
The hrtimer code is written mainly with CLOCK_REALTIME and CLOCK_MONOTONIC
in mind. These are clockids 0 and 1 resepctively. However, if we are
to introduce any new hrtimer bases, using new clockids, we have to skip
the cputimers (clockids 2,3) as well as other clockids that may not impelement
timers.This patch adds a little bit of indirection between the clockid and
the base, so that we can extend the base by one when we add
a new clockid at number 7 or so.CC: Jamie Lokier
CC: Thomas Gleixner
CC: Alexander Shishkin
CC: Arve Hjønnevåg
Signed-off-by: John Stultz
10 Jan, 2011
1 commit
-
Fix new kernel-doc notation warning in hrtimer.h:
Warning(include/linux/hrtimer.h:150): Excess struct/union/enum/typedef member 'first' description in 'hrtimer_clock_base'
Signed-off-by: Randy Dunlap
Signed-off-by: Linus Torvalds
11 Dec, 2010
1 commit
-
Converts the hrtimer code to use the new timerlist infrastructure
Signed-off-by: John Stultz
LKML Reference:
Reviewed-by: Thomas Gleixner
CC: Alessandro Zummo
CC: Thomas Gleixner
CC: Richard Cochran
10 Nov, 2010
1 commit
-
curr_timer doesn't resident in struct hrtimer_cpu_base anymore.
Signed-off-by: Yong Zhang
LKML-Reference:
Signed-off-by: Thomas Gleixner
07 Apr, 2010
1 commit
-
The current version of schedule_hrtimeout() always uses the
monotonic clock. Some system calls such as mq_timedsend()
and mq_timedreceive(), however, require the use of the wall
clock due to the definition of the system call.This patch provides the infrastructure to use schedule_hrtimeout()
with a CLOCK_REALTIME timer.Signed-off-by: Carsten Emde
Tested-by: Pradyumna Sampath
Cc: Andrew Morton
Cc: Arjan van de Veen
LKML-Reference:
Signed-off-by: Thomas Gleixner
15 Dec, 2009
1 commit
-
Convert locks which cannot be sleeping locks in preempt-rt to
raw_spinlocks.Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra
Acked-by: Ingo Molnar
10 Dec, 2009
2 commits
-
There is no reason to make timer_stats_hrtimer_set_start_info and
friends visible to the rest of the kernel. So move all of them to
hrtimer.c. Also make timer_stats_hrtimer_set_start_info a static
inline function so it gets inlined and we avoid another function call.
Based on a patch by Thomas Gleixner.Signed-off-by: Heiko Carstens
LKML-Reference:
Signed-off-by: Thomas Gleixner -
The hrtimer_interrupt hang logic adjusts min_delta_ns based on the
execution time of the hrtimer callbacks.This is error-prone for virtual machines, where a guest vcpu can be
scheduled out during the execution of the callbacks (and the callbacks
themselves can do operations that translate to blocking operations in
the hypervisor), which in can lead to large min_delta_ns rendering the
system unusable.Replace the current heuristics with something more reliable. Allow the
interrupt code to try 3 times to catch up with the lost time. If that
fails use the total time spent in the interrupt handler to defer the
next timer interrupt so the system can catch up with other things
which got delayed. Limit that deferment to 100ms.The retry events and the maximum time spent in the interrupt handler
are recorded and exposed via /proc/timer_listInspired by a patch from Marcelo.
Reported-by: Michael Tokarev
Signed-off-by: Thomas Gleixner
Tested-by: Marcelo Tosatti
Cc: kvm@vger.kernel.org
20 Nov, 2009
1 commit
-
commit 507e1231 (timer stats: Optimize by adding quick check to avoid
function calls) introduced a regression in /proc/timer_list./proc/timer_list shows now
#0: , tick_sched_timer, S:01, , /-1
instead of
#0: , tick_sched_timer, S:01, hrtimer_start, swapper/0Revert the hrtimer quick check for now. The optimization needs more
thought, but this is neither 2.6.32-rc7 nor stable material.[ tglx: - Removed unrelated changes from the original patch
- Prevent unneccesary call to timer_stats_update_stats
- massaged the changelog ]Signed-off-by: Feng Tang
LKML-Reference:
Cc: Heiko Carstens
Cc: stable@kernel.org
Signed-off-by: Andrew Morton
Signed-off-by: Thomas Gleixner
14 Aug, 2009
1 commit
-
Reason: Martin's timekeeping cleanup series depends on both
timers/core and mainline changes.Signed-off-by: Thomas Gleixner
22 Jul, 2009
1 commit
-
It's unused, remove it.
Signed-off-by: Peter Zijlstra
Signed-off-by: Thomas Gleixner
LKML-Reference:
11 Jul, 2009
1 commit
-
git commit 507e1231 "timer stats: Optimize by adding quick check to
avoid function calls" added one wrong check so that one unnecessary
function call isn't elimated.time_stats_account_hrtimer() checks if timer->start_pid isn't
initialized in order to find out if timer_stats_update_stats() should
be called. However start_pid is initialized with -1 instead of 0, so
that the function call always happens.Check timer->start_site like in timer_stats_account_timer() to fix
this.Signed-off-by: Heiko Carstens
Signed-off-by: Thomas Gleixner
24 Jun, 2009
1 commit
-
When the kernel is configured with CONFIG_TIMER_STATS but timer
stats are runtime disabled we still get calls to
__timer_stats_timer_set_start_info which initializes some
fields in the corresponding struct timer_list.So add some quick checks in the the timer stats setup functions
to avoid function calls to __timer_stats_timer_set_start_info
when timer stats are disabled.In an artificial workload that does nothing but playing ping
pong with a single tcp packet via loopback this decreases cpu
consumption by 1 - 1.5%.This is part of a modified function trace output on SLES11:
perl-2497 [00] 28630647177732388 [+ 125]: sk_reset_timer
Cc: Andrew Morton
Cc: Martin Schwidefsky
Cc: Mustafa Mesanovic
Cc: Arjan van de Ven
LKML-Reference:
Signed-off-by: Ingo Molnar
13 May, 2009
1 commit
-
* Arun R Bharadwaj [2009-04-16 12:11:36]:
This patch creates a new framework for identifying cpu-pinned timers
and hrtimers.This framework is needed because pinned timers are expected to fire on
the same CPU on which they are queued. So it is essential to identify
these and not migrate them, in case there are any.For regular timers, the currently existing add_timer_on() can be used
queue pinned timers and subsequently mod_timer_pinned() can be used
to modify the 'expires' field.For hrtimers, new modes HRTIMER_ABS_PINNED and HRTIMER_REL_PINNED are
added to queue cpu-pinned hrtimer.[ tglx: use .._PINNED mode argument instead of creating tons of new
functions ]Signed-off-by: Arun R Bharadwaj
Signed-off-by: Thomas Gleixner
31 Mar, 2009
1 commit
-
It appears I inadvertly introduced rq->lock recursion to the
hrtimer_start() path when I delegated running already expired
timers to softirq context.This patch fixes it by introducing a __hrtimer_start_range_ns()
method that will not use raise_softirq_irqoff() but
__raise_softirq_irqoff() which avoids the wakeup.It then also changes schedule() to check for pending softirqs and
do the wakeup then, I'm not quite sure I like this last bit, nor
am I convinced its really needed.Signed-off-by: Peter Zijlstra
Cc: Peter Zijlstra
Cc: paulus@samba.org
LKML-Reference:
Signed-off-by: Ingo Molnar
25 Nov, 2008
1 commit
-
Impact: cleanup, move all hrtimer processing into hardirq context
This is an attempt at removing some of the hrtimer complexity by
reducing the number of callback modes to 1.This means that all hrtimer callback functions will be ran from HARD-irq
context.I went through all the 30 odd hrtimer callback functions in the kernel
and saw only one that I'm not quite sure of, which is the one in
net/can/bcm.c - hence I'm CC-ing the folks responsible for that code.Furthermore, the hrtimer core now calls callbacks directly with IRQs
disabled in case you try to enqueue an expired timer. If this timer is a
periodic timer (which should use hrtimer_forward() to advance its time)
then it might be possible to end up in an inf. recursive loop due to the
fact that hrtimer_forward() doesn't round up to the next timer
granularity, and therefore keeps on calling the callback - obviously
this needs a fix.Aside from that, this seems to compile and actually boot on my dual core
test box - although I'm sure there are some bugs in, me not hitting any
makes me certain :-)Signed-off-by: Peter Zijlstra
Signed-off-by: Ingo Molnar
12 Nov, 2008
1 commit
-
Impact: cleanup
git grep HRTIMER_CB_IRQSAFE revealed half the callback modes are actually
unused.Signed-off-by: Peter Zijlstra
Signed-off-by: Ingo Molnar
07 Nov, 2008
1 commit
-
Fix the hrtimer_add_expires_ns() function. It should take a 'u64 ns' argument,
but rather takes an 'unsigned long ns' argument - which might only be 32-bits.On FRV, this results in the kernel locking up because hrtimer_forward() passes
the result of a 64-bit multiplication to this function, for which the compiler
discards the top 32-bits - something that didn't happen when ktime_add_ns() was
called directly.Signed-off-by: David Howells
Acked-by: Arjan van de Ven
Signed-off-by: Linus Torvalds
22 Oct, 2008
1 commit
-
Conflicts:
kernel/time/tick-sched.c
Signed-off-by: Thomas Gleixner
20 Oct, 2008
2 commits
-
Signed-off-by: Thomas Gleixner
-
…tp', 'timers/posixtimers' and 'timers/debug' into v28-timers-for-linus
18 Oct, 2008
1 commit
-
Conflicts:
arch/x86/kvm/i8254.c
15 Oct, 2008
1 commit
-
Signed-off-by: Stephen Rothwell
08 Oct, 2008
1 commit
-
the timer peek function was on the wrong side of an ifdef,
breaking for the !HRTIMERs case. Just provide an empty inline
for that case since it doesn't make sense in that scenario.Signed-off-by: Arjan van de Ven
29 Sep, 2008
2 commits
-
Impact: per CPU hrtimers can be migrated from a dead CPU
The hrtimer code has no knowledge about per CPU timers, but we need to
prevent the migration of such timers and warn when such a timer is
active at migration time.Explicitely mark the timers as per CPU and use a more understandable
mode descriptor for the interrupts safe unlocked callback mode, which
is used by hrtimer_sleeper and the scheduler code.Signed-off-by: Thomas Gleixner
-
Impact: during migration active hrtimers can be seen as inactive
The migration code removes the hrtimers from the queues of the dead
CPU and sets the state temporary to INACTIVE. The enqueue code sets it
to ACTIVE/PENDING again.Prevent that the wrong state can be seen by using a separate migration
state bit.Signed-off-by: Thomas Gleixner
24 Sep, 2008
1 commit
-
reorder struct hrtimer to save 8 bytes on 64 bit builds when
CONFIG_TIMER_STATS selected. (also removes 8 bytes from signal_struct)Signed-off-by: Richard Kennedy
Signed-off-by: Andrew Morton
Signed-off-by: Thomas Gleixner
22 Sep, 2008
2 commits
-
hrtimer_clock_base::reprogram() also appears to never
have been used, so remove it.Signed-off-by: Mark McLoughlin
Signed-off-by: Ingo Molnar -
Peter Zijlstra noticed this 8 months ago and I just noticed
it again.hrtimer_clock_base::get_softirq_time() is currently unused
in the entire tree. In fact, looking at the logs, it appears
as if it was never used. Remove it.Signed-off-by: Mark McLoughlin
Signed-off-by: Ingo Molnar
11 Sep, 2008
1 commit
-
As part of going idle, we already look at the time of the next timer event to determine
which C-state to select etc.This patch adds functionality that causes the timers that are past their
soft expire time, to fire at this time, before we calculate the next wakeup
time. This functionality will thus avoid wakeups by running timers before
going idle rather than specially waking up for it.Signed-off-by: Arjan van de Ven