search for: clockevents

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 f...

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 f...

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 variabl...

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

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

4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michael Kelley <mikelley at microsoft.com> commit 35b69a420bfb56b7b74cb635ea903db05e357bec upstream. 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

4.19-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michael Kelley <mikelley at microsoft.com> commit 35b69a420bfb56b7b74cb635ea903db05e357bec upstream. 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

4.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michael Kelley <mikelley at microsoft.com> commit 35b69a420bfb56b7b74cb635ea903db05e357bec upstream. 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

4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michael Kelley <mikelley at microsoft.com> commit 35b69a420bfb56b7b74cb635ea903db05e357bec upstream. 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

4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michael Kelley <mikelley at microsoft.com> commit 35b69a420bfb56b7b74cb635ea903db05e357bec upstream. 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

3.16.63-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Michael Kelley <mikelley at microsoft.com> commit 35b69a420bfb56b7b74cb635ea903db05e357bec upstream. 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

...tands: using an absolute timeout only works if the kernel and hypervisor have non-drifting timebases. I think its too fragile for a clockevent implementation to assume that a particular clocksource is in use to get reliable results. Or perhaps this is a property of the whole clock subsystem: that clockevents must be paired with clocksources. But its not obvious to me that this enforced, or even acknowledged. (Of course, if the drift can be characterized, then you can compensate for it, but this seems too complex to be the right answer. And drift compensation is numerically much simpler for small 32-...

...tands: using an absolute timeout only works if the kernel and hypervisor have non-drifting timebases. I think its too fragile for a clockevent implementation to assume that a particular clocksource is in use to get reliable results. Or perhaps this is a property of the whole clock subsystem: that clockevents must be paired with clocksources. But its not obvious to me that this enforced, or even acknowledged. (Of course, if the drift can be characterized, then you can compensate for it, but this seems too complex to be the right answer. And drift compensation is numerically much simpler for small 32-...

...vt->max_delta_ns = clockevent_delta2ns(ULONG_MAX, evt); + evt->min_delta_ns = clockevent_delta2ns(1, evt); + evt->cpumask = cpumask_of_cpu(cpu); + + printk(KERN_WARNING "vmi: registering clock event %s. mult=%lu shift=%u\n", + evt->name, evt->mult, evt->shift); + clockevents_register_device(evt); +} + +void __init vmi_time_init(void) +{ + /* Disable PIT: BIOSes start PIT CH0 with 18.2hz peridic. */ + outb_p(0x3a, PIT_MODE); /* binary, mode 5, LSB/MSB, ch 0 */ + + vmi_time_init_clockevent(); + setup_irq(0, &vmi_clock_action); +} + +#ifdef CONFIG_X86_LOCAL_APIC +void...

...vt->max_delta_ns = clockevent_delta2ns(ULONG_MAX, evt); + evt->min_delta_ns = clockevent_delta2ns(1, evt); + evt->cpumask = cpumask_of_cpu(cpu); + + printk(KERN_WARNING "vmi: registering clock event %s. mult=%lu shift=%u\n", + evt->name, evt->mult, evt->shift); + clockevents_register_device(evt); +} + +void __init vmi_time_init(void) +{ + /* Disable PIT: BIOSes start PIT CH0 with 18.2hz peridic. */ + outb_p(0x3a, PIT_MODE); /* binary, mode 5, LSB/MSB, ch 0 */ + + vmi_time_init_clockevent(); + setup_irq(0, &vmi_clock_action); +} + +#ifdef CONFIG_X86_LOCAL_APIC +void...

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