search for: clockevent

This is a note to let you know that I've just added the patch titled clockevents/drivers/i8253: Add support for PIT shutdown quirk to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: clockevents-drivers-i8253-add-support-for-pit-shutdown-quirk.patch and it can be...

This is a note to let you know that I've just added the patch titled clockevents/drivers/i8253: Add support for PIT shutdown quirk to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: clockevents-drivers-i8253-add-support-for-pit-shutdown-quirk.patch and it can be...

This is a note to let you know that I've just added the patch titled clockevents/drivers/i8253: Add support for PIT shutdown quirk to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: clockevents-drivers-i8253-add-support-for-pit-shutdown-quirk.patch and it can be...

This is a note to let you know that I've just added the patch titled clockevents/drivers/i8253: Add support for PIT shutdown quirk to the 4.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: clockevents-drivers-i8253-add-support-for-pit-shutdown-quirk.patch and it can be...

This is a note to let you know that I've just added the patch titled clockevents/drivers/i8253: Add support for PIT shutdown quirk to the 4.19-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: clockevents-drivers-i8253-add-support-for-pit-shutdown-quirk.patch and it can be...

...03db05e357bec Gitweb: https://git.kernel.org/tip/35b69a420bfb56b7b74cb635ea903db05e357bec Author: Michael Kelley <mikelley at microsoft.com> AuthorDate: Sun, 4 Nov 2018 03:48:54 +0000 Committer: Thomas Gleixner <tglx at linutronix.de> CommitDate: Sun, 4 Nov 2018 11:04:46 +0100 clockevents/drivers/i8253: Add support for PIT shutdown quirk Add support for platforms where pit_shutdown() doesn't work because of a quirk in the PIT emulation. On these platforms setting the counter register to zero causes the PIT to start running again, negating the shutdown. Provide a global variab...

Ingo Molnar wrote: > * Ingo Molnar <mingo@elte.hu> wrote: > > >> no, that's not the case: next_timer_interrupt() is the NO_IDLE_HZ >> method of doing things - while in the NO_HZ case you are supposed to >> use clockevent devices to program timer hardware. >> We don't have a clockevent device. But we need NO_IDLE_HZ support, which NO_HZ has now subsumed. > a proper CE device also has the added bonus of making high-res timers > guests work automatically. It should be simple: just pass it thr...

Ingo Molnar wrote: > * Ingo Molnar <mingo@elte.hu> wrote: > > >> no, that's not the case: next_timer_interrupt() is the NO_IDLE_HZ >> method of doing things - while in the NO_HZ case you are supposed to >> use clockevent devices to program timer hardware. >> We don't have a clockevent device. But we need NO_IDLE_HZ support, which NO_HZ has now subsumed. > a proper CE device also has the added bonus of making high-res timers > guests work automatically. It should be simple: just pass it thr...

...+ } raw_spin_unlock(&i8253_lock); return 0; --- a/include/linux/i8253.h +++ b/include/linux/i8253.h @@ -21,6 +21,7 @@ #define PIT_LATCH ((PIT_TICK_RATE + HZ/2) / HZ) extern raw_spinlock_t i8253_lock; +extern bool i8253_clear_counter_on_shutdown; extern struct clock_event_device i8253_clockevent; extern void clockevent_i8253_init(bool oneshot);

...+ } raw_spin_unlock(&i8253_lock); return 0; --- a/include/linux/i8253.h +++ b/include/linux/i8253.h @@ -21,6 +21,7 @@ #define PIT_LATCH ((PIT_TICK_RATE + HZ/2) / HZ) extern raw_spinlock_t i8253_lock; +extern bool i8253_clear_counter_on_shutdown; extern struct clock_event_device i8253_clockevent; extern void clockevent_i8253_init(bool oneshot);

...+ } raw_spin_unlock(&i8253_lock); return 0; --- a/include/linux/i8253.h +++ b/include/linux/i8253.h @@ -21,6 +21,7 @@ #define PIT_LATCH ((PIT_TICK_RATE + HZ/2) / HZ) extern raw_spinlock_t i8253_lock; +extern bool i8253_clear_counter_on_shutdown; extern struct clock_event_device i8253_clockevent; extern void clockevent_i8253_init(bool oneshot);

...+ } raw_spin_unlock(&i8253_lock); return 0; --- a/include/linux/i8253.h +++ b/include/linux/i8253.h @@ -21,6 +21,7 @@ #define PIT_LATCH ((PIT_TICK_RATE + HZ/2) / HZ) extern raw_spinlock_t i8253_lock; +extern bool i8253_clear_counter_on_shutdown; extern struct clock_event_device i8253_clockevent; extern void clockevent_i8253_init(bool oneshot);

...+ } raw_spin_unlock(&i8253_lock); return 0; --- a/include/linux/i8253.h +++ b/include/linux/i8253.h @@ -21,6 +21,7 @@ #define PIT_LATCH ((PIT_TICK_RATE + HZ/2) / HZ) extern raw_spinlock_t i8253_lock; +extern bool i8253_clear_counter_on_shutdown; extern struct clock_event_device i8253_clockevent; extern void clockevent_i8253_init(bool oneshot);

...CH0); + outb_p(0, PIT_CH0); + } } break; --- a/include/linux/i8253.h +++ b/include/linux/i8253.h @@ -21,6 +21,7 @@ #define PIT_LATCH ((PIT_TICK_RATE + HZ/2) / HZ) extern raw_spinlock_t i8253_lock; +extern bool i8253_clear_counter_on_shutdown; extern struct clock_event_device i8253_clockevent; extern void clockevent_i8253_init(bool oneshot);

...d. If they're operating off the same timebase, then in principle you can work out a constant offset between the two, and use that for converting a kernel absolute time into a hypervisor absolute time. When booting under Xen, you'll get this if you're using both the xen clocksource and clockevent drivers. However, it seems that during boot on a NO_HZ HIGHRES_TIMERS system, the kernel does not use the Xen clocksource until it switches to highres timer mode. This means that during boot the kernel's monotonic clock is drifting with respect to the hypervisor, and all timeouts are unreliab...

...d. If they're operating off the same timebase, then in principle you can work out a constant offset between the two, and use that for converting a kernel absolute time into a hypervisor absolute time. When booting under Xen, you'll get this if you're using both the xen clocksource and clockevent drivers. However, it seems that during boot on a NO_HZ HIGHRES_TIMERS system, the kernel does not use the Xen clocksource until it switches to highres timer mode. This means that during boot the kernel's monotonic clock is drifting with respect to the hypervisor, and all timeouts are unreliab...

...+ +static void ack_timer_irq(unsigned int irq) +{ + ack_APIC_irq(); +} + +static struct irq_chip vmi_chip __read_mostly = { + .name = "VMI-LOCAL", + .startup = startup_timer_irq, + .mask = mask_timer_irq, + .unmask = unmask_timer_irq, + .ack = ack_timer_irq +}; +#endif + +/** vmi clockevent */ +#define VMI_ALARM_WIRED_IRQ0 0x00000000 +#define VMI_ALARM_WIRED_LVTT 0x00010000 +static int vmi_wiring = VMI_ALARM_WIRED_IRQ0; + +static inline int vmi_get_alarm_wiring(void) +{ + return vmi_wiring; +} + +static void vmi_timer_set_mode(enum clock_event_mode mode, + struct clock...

...+ +static void ack_timer_irq(unsigned int irq) +{ + ack_APIC_irq(); +} + +static struct irq_chip vmi_chip __read_mostly = { + .name = "VMI-LOCAL", + .startup = startup_timer_irq, + .mask = mask_timer_irq, + .unmask = unmask_timer_irq, + .ack = ack_timer_irq +}; +#endif + +/** vmi clockevent */ +#define VMI_ALARM_WIRED_IRQ0 0x00000000 +#define VMI_ALARM_WIRED_LVTT 0x00010000 +static int vmi_wiring = VMI_ALARM_WIRED_IRQ0; + +static inline int vmi_get_alarm_wiring(void) +{ + return vmi_wiring; +} + +static void vmi_timer_set_mode(enum clock_event_mode mode, + struct clock...

Hi there, I am getting very low throughput (around 0.29Mbps) while running netperf benchmark for guest to guest communication on a single physical host. To analyse where the time is spent in hypervisor I wanna use profiling. Please help me choosing good profiler according to my requirments. Should it be better in my case, Xentrace, gprof, xenoprof  or Oprofile. Is it possible to use some vtune

Hi there, I am getting very low throughput (around 0.29Mbps) while running netperf benchmark for guest to guest communication on a single physical host. To analyse where the time is spent in hypervisor I wanna use profiling. Please help me choosing good profiler according to my requirments. Should it be better in my case, Xentrace, gprof, xenoprof  or Oprofile. Is it possible to use some vtune