22 Dec, 2011

1 commit

  • This isn't needed in the clockevents.c file, and the header file is
    going away soon, so just remove the #include

    Cc: Thomas Gleixner
    Signed-off-by: Kay Sievers
    Signed-off-by: Greg Kroah-Hartman

    Kay Sievers
     

08 Sep, 2011

2 commits

  • There is at least one architecture (s390) with a sane clockevent device
    that can be programmed with the equivalent of a ktime. No need to create
    a delta against the current time, the ktime can be used directly.

    A new clock device function 'set_next_ktime' is introduced that is called
    with the unmodified ktime for the timer if the clock event device has the
    CLOCK_EVT_FEAT_KTIME bit set.

    Signed-off-by: Martin Schwidefsky
    Cc: john stultz
    Link: http://lkml.kernel.org/r/20110823133142.815350967@de.ibm.com
    Signed-off-by: Thomas Gleixner

    Martin Schwidefsky
     
  • The automatic increase of the min_delta_ns of a clockevents device
    should be done in the clockevents code as the minimum delay is an
    attribute of the clockevents device.

    In addition not all architectures want the automatic adjustment, on a
    massively virtualized system it can happen that the programming of a
    clock event fails several times in a row because the virtual cpu has
    been rescheduled quickly enough. In that case the minimum delay will
    erroneously be increased with no way back. The new config symbol
    GENERIC_CLOCKEVENTS_MIN_ADJUST is used to enable the automatic
    adjustment. The config option is selected only for x86.

    Signed-off-by: Martin Schwidefsky
    Cc: john stultz
    Link: http://lkml.kernel.org/r/20110823133142.494157493@de.ibm.com
    Signed-off-by: Thomas Gleixner

    Martin Schwidefsky
     

03 Jun, 2011

1 commit

  • For UP it's stupid to request an initialized cpumask for the clock
    event devices. Though we need the mask set even on UP to avoid a
    horrible ifdeffery especially in the broadcast code.

    For SMP we can at least try to survive with a warning and set the
    cpumask of the cpu we're running on. That gives a decent chance to
    bring the machine up and retrieve the debug info.

    Signed-off-by: Thomas Gleixner
    Cc: Linus Walleij
    Cc: Russell King - ARM Linux
    Cc: Stephen Boyd

    Thomas Gleixner
     

20 May, 2011

1 commit


19 May, 2011

2 commits


01 Feb, 2011

1 commit

  • All callers of do_timer() are converted to xtime_update(). The only
    users of xtime_lock are in kernel/time/. Make both local to
    kernel/time/ and remove them from the global header files.

    [ tglx: Reuse tick-internal.h instead of creating another local header
    file. Massaged changelog ]

    Signed-off-by: Torben Hohn
    Cc: Peter Zijlstra
    Cc: johnstul@us.ibm.com
    Cc: yong.zhang0@gmail.com
    Cc: hch@infradead.org
    Signed-off-by: Thomas Gleixner

    Torben Hohn
     

18 Jan, 2010

1 commit

  • Marc reported that the BUG_ON in clockevents_notify() triggers on his
    system. This happens because the kernel tries to remove an active
    clock event device (used for broadcasting) from the device list.

    The handling of devices which can be used as per cpu device and as a
    global broadcast device is suboptimal.

    The simplest solution for now (and for stable) is to check whether the
    device is used as global broadcast device, but this needs to be
    revisited.

    [ tglx: restored the cpuweight check and massaged the changelog ]

    Reported-by: Marc Dionne
    Tested-by: Marc Dionne
    Signed-off-by: Xiaotian Feng
    LKML-Reference:
    Signed-off-by: Thomas Gleixner
    Cc: stable@kernel.org

    Xiaotian Feng
     

20 Dec, 2009

1 commit


15 Dec, 2009

1 commit


11 Dec, 2009

1 commit

  • Xiaotian Feng triggered a list corruption in the clock events list on
    CPU hotplug and debugged the root cause.

    If a CPU registers more than one per cpu clock event device, then only
    the active clock event device is removed on CPU_DEAD. The unused
    devices are kept in the clock events device list.

    On CPU up the clock event devices are registered again, which means
    that we list_add an already enqueued list_head. That results in list
    corruption.

    Resolve this by removing all devices which are associated to the dead
    CPU on CPU_DEAD.

    Reported-by: Xiaotian Feng
    Signed-off-by: Thomas Gleixner
    Tested-by: Xiaotian Feng
    Cc: stable@kernel.org

    Thomas Gleixner
     

18 Nov, 2009

1 commit

  • Include "tick-internal.h" in order to pick up the extern function
    prototype for clockevents_shutdown(). This quiets the following sparse
    build noise:

    warning: symbol 'clockevents_shutdown' was not declared. Should it be static?

    Signed-off-by: H Hartley Sweeten
    LKML-Reference:
    Reviewed-by: Yong Zhang
    Cc: johnstul@us.ibm.com
    Signed-off-by: Andrew Morton
    Signed-off-by: Thomas Gleixner

    H Hartley Sweeten
     

14 Nov, 2009

1 commit

  • In the dynamic tick code, "max_delta_ns" (member of the
    "clock_event_device" structure) represents the maximum sleep time
    that can occur between timer events in nanoseconds.

    The variable, "max_delta_ns", is defined as an unsigned long
    which is a 32-bit integer for 32-bit machines and a 64-bit
    integer for 64-bit machines (if -m64 option is used for gcc).
    The value of max_delta_ns is set by calling the function
    "clockevent_delta2ns()" which returns a maximum value of LONG_MAX.
    For a 32-bit machine LONG_MAX is equal to 0x7fffffff and in
    nanoseconds this equates to ~2.15 seconds. Hence, the maximum
    sleep time for a 32-bit machine is ~2.15 seconds, where as for
    a 64-bit machine it will be many years.

    This patch changes the type of max_delta_ns to be "u64" instead of
    "unsigned long" so that this variable is a 64-bit type for both 32-bit
    and 64-bit machines. It also changes the maximum value returned by
    clockevent_delta2ns() to KTIME_MAX. Hence this allows a 32-bit
    machine to sleep for longer than ~2.15 seconds. Please note that this
    patch also changes "min_delta_ns" to be "u64" too and although this is
    unnecessary, it makes the patch simpler as it avoids to fixup all
    callers of clockevent_delta2ns().

    [ tglx: changed "unsigned long long" to u64 as we use this data type
    through out the time code ]

    Signed-off-by: Jon Hunter
    Cc: John Stultz
    LKML-Reference:
    Signed-off-by: Thomas Gleixner

    Jon Hunter
     

20 Aug, 2009

1 commit

  • Currently clockevents_notify() is called with interrupts enabled at
    some places and interrupts disabled at some other places.

    This results in a deadlock in this scenario.

    cpu A holds clockevents_lock in clockevents_notify() with irqs enabled
    cpu B waits for clockevents_lock in clockevents_notify() with irqs disabled
    cpu C doing set_mtrr() which will try to rendezvous of all the cpus.

    This will result in C and A come to the rendezvous point and waiting
    for B. B is stuck forever waiting for the spinlock and thus not
    reaching the rendezvous point.

    Fix the clockevents code so that clockevents_lock is taken with
    interrupts disabled and thus avoid the above deadlock.

    Also call lapic_timer_propagate_broadcast() on the destination cpu so
    that we avoid calling smp_call_function() in the clockevents notifier
    chain.

    This issue left us wondering if we need to change the MTRR rendezvous
    logic to use stop machine logic (instead of smp_call_function) or add
    a check in spinlock debug code to see if there are other spinlocks
    which gets taken under both interrupts enabled/disabled conditions.

    Signed-off-by: Suresh Siddha
    Signed-off-by: Venkatesh Pallipadi
    Cc: "Pallipadi Venkatesh"
    Cc: "Brown Len"
    LKML-Reference:
    Signed-off-by: Thomas Gleixner

    Suresh Siddha
     

10 Jul, 2009

1 commit

  • The timer migration expiry check should prevent the migration of a
    timer to another CPU when the timer expires before the next event is
    scheduled on the other CPU. Migrating the timer might delay it because
    we can not reprogram the clock event device on the other CPU. But the
    code implementing that check has two flaws:

    - for !HIGHRES the check compares the expiry value with the clock
    events device expiry value which is wrong for CLOCK_REALTIME based
    timers.

    - the check is racy. It holds the hrtimer base lock of the target CPU,
    but the clock event device expiry value can be modified
    nevertheless, e.g. by an timer interrupt firing.

    The !HIGHRES case is easy to fix as we can enqueue the timer on the
    cpu which was selected by the load balancer. It runs the idle
    balancing code once per jiffy anyway. So the maximum delay for the
    timer is the same as when we keep the tick on the current cpu going.

    In the HIGHRES case we can get the next expiry value from the hrtimer
    cpu_base of the target CPU and serialize the update with the cpu_base
    lock. This moves the lock section in hrtimer_interrupt() so we can set
    next_event to KTIME_MAX while we are handling the expired timers and
    set it to the next expiry value after we handled the timers under the
    base lock. While the expired timers are processed timer migration is
    blocked because the expiry time of the timer is always

    Thomas Gleixner
     

16 Jun, 2009

1 commit

  • …kernel/git/tip/linux-2.6-tip

    * 'timers-for-linus-migration' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    timers: Logic to move non pinned timers
    timers: /proc/sys sysctl hook to enable timer migration
    timers: Identifying the existing pinned timers
    timers: Framework for identifying pinned timers
    timers: allow deferrable timers for intervals tv2-tv5 to be deferred

    Fix up conflicts in kernel/sched.c and kernel/timer.c manually

    Linus Torvalds
     

13 May, 2009

1 commit

  • * Arun R Bharadwaj [2009-04-16 12:11:36]:

    This patch migrates all non pinned timers and hrtimers to the current
    idle load balancer, from all the idle CPUs. Timers firing on busy CPUs
    are not migrated.

    While migrating hrtimers, care should be taken to check if migrating
    a hrtimer would result in a latency or not. So we compare the expiry of the
    hrtimer with the next timer interrupt on the target cpu and migrate the
    hrtimer only if it expires *after* the next interrupt on the target cpu.
    So, added a clockevents_get_next_event() helper function to return the
    next_event on the target cpu's clock_event_device.

    [ tglx: cleanups and simplifications ]

    Signed-off-by: Arun R Bharadwaj
    Signed-off-by: Thomas Gleixner

    Arun R Bharadwaj
     

02 May, 2009

1 commit

  • Export the following symbols using EXPORT_SYMBOL_GPL:
    - clockevent_delta2ns
    - clockevents_register_device

    This allows us to build SuperH clockevent and clocksource
    drivers as modules, see drivers/clocksource/sh_*.c

    [ Impact: allow modular build of clockevent drivers ]

    Signed-off-by: Magnus Damm
    LKML-Reference:
    Signed-off-by: Thomas Gleixner

    Magnus Damm
     

16 Jan, 2009

1 commit

  • Allow the set_mode() clockevent callback to decide and fill in delta
    details such as shift, mult, max_delta_ns and min_delta_ns.

    With this change the clockevent can be registered without delta details
    which allows us to keep the parent clock disabled until the clockevent
    gets setup using set_mode().

    Letting set_mode() fill in or update delta details allows us to save
    power by disabling the parent clock while the clockevent is unused.
    This may however make the parent clock rate change, so next time the
    clockevent gets enabled we need let set_mode() to update the detla
    details accordingly. Doing it at registration time is not enough.

    Furthermore, the delta details seem unused in the case of periodic-only
    clockevent drivers, so this change also allows registration of such
    drivers without the delta details filled in.

    Signed-off-by: Magnus Damm
    Signed-off-by: Thomas Gleixner

    Magnus Damm
     

13 Dec, 2008

1 commit


17 Sep, 2008

1 commit

  • The device shut down does not cleanup the next_event variable of the
    clock event device. So when the device is reactivated the possible
    stale next_event value can prevent the device to be reprogrammed as it
    claims to wait on a event already.

    This is the root cause of the resurfacing suspend/resume problem,
    where systems need key press to come back to life.

    Fix this by setting next_event to KTIME_MAX when the device is shut
    down. Use a separate function for shutdown which takes care of that
    and only keep the direct set mode call in the broadcast code, where we
    can not touch the next_event value.

    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

05 Sep, 2008

1 commit

  • There is a ordering related problem with clockevents code, due to which
    clockevents_register_device() called after tickless/highres switch
    will not work. The new clockevent ends up with clockevents_handle_noop as
    event handler, resulting in no timer activity.

    The problematic path seems to be

    * old device already has hrtimer_interrupt as the event_handler
    * new clockevent device registers with a higher rating
    * tick_check_new_device() is called
    * clockevents_exchange_device() gets called
    * old->event_handler is set to clockevents_handle_noop
    * tick_setup_device() is called for the new device
    * which sets new->event_handler using the old->event_handler which is noop.

    Change the ordering so that new device inherits the proper handler.

    This does not have any issue in normal case as most likely all the clockevent
    devices are setup before the highres switch. But, can potentially be affecting
    some corner case where HPET force detect happens after the highres switch.
    This was a problem with HPET in MSI mode code that we have been experimenting
    with.

    Signed-off-by: Venkatesh Pallipadi
    Signed-off-by: Shaohua Li
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar

    Venkatesh Pallipadi
     

09 Feb, 2008

2 commits

  • Fix typo in comments.

    BTW: I have to fix coding style in arch/ia64/kernel/time.c also, otherwise
    checkpatch.pl will be complaining.

    Signed-off-by: Li Zefan
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: john stultz
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Li Zefan
     
  • list_for_each_safe() suffices here.

    Signed-off-by: Li Zefan
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: john stultz
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Li Zefan
     

30 Jan, 2008

1 commit


08 Dec, 2007

1 commit


13 Oct, 2007

1 commit


12 Aug, 2007

1 commit


17 Jul, 2007

1 commit


27 Mar, 2007

1 commit


17 Feb, 2007

1 commit

  • Architectures register their clock event devices, in the clock events core.
    Users of the clockevents core can get clock event devices for their use. The
    clockevents core code provides notification mechanisms for various clock
    related management events.

    This allows to control the clock event devices without the architectures
    having to worry about the details of function assignment. This is also a
    preliminary for high resolution timers and dynamic ticks to allow the core
    code to control the clock functionality without intrusive changes to the
    architecture code.

    [Fixes-by: Ingo Molnar ]
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar
    Cc: Roman Zippel
    Cc: john stultz
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Gleixner