search for: no_hz

Given all the discussion, let's just require NO_HZ when CONFIG_PARAVIRT. Anyone object? Signed-off-by: Chris Wright <chrisw@sous-sol.org> --- --- a/arch/i386/Kconfig Mon Mar 12 11:07:45 2007 -0700 +++ b/arch/i386/Kconfig Mon Mar 12 16:53:14 2007 -0700 @@ -208,7 +208,7 @@ endchoice config PARAVIRT bool "Paravirtualization support...

Given all the discussion, let's just require NO_HZ when CONFIG_PARAVIRT. Anyone object? Signed-off-by: Chris Wright <chrisw@sous-sol.org> --- --- a/arch/i386/Kconfig Mon Mar 12 11:07:45 2007 -0700 +++ b/arch/i386/Kconfig Mon Mar 12 16:53:14 2007 -0700 @@ -208,7 +208,7 @@ endchoice config PARAVIRT bool "Paravirtualization support...

...rinciple 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 unreliable. Initially I was just computing the kernel-hyperviso...

...rinciple 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 unreliable. Initially I was just computing the kernel-hyperviso...

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

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

The softlockup watchdog is currently a nuisance in a virtual machine, since the whole system could have the CPU stolen from it for a long period of time. While it would be unlikely for a guest domain to be denied timer interrupts for over 10s, it could happen and any softlockup message would be completely spurious. Earlier I proposed that sched_clock() return time in unstolen nanoseconds, which

The softlockup watchdog is currently a nuisance in a virtual machine, since the whole system could have the CPU stolen from it for a long period of time. While it would be unlikely for a guest domain to be denied timer interrupts for over 10s, it could happen and any softlockup message would be completely spurious. Earlier I proposed that sched_clock() return time in unstolen nanoseconds, which

...ed on the errata page: "Due to prematurely decremented calc_load_task, the calculated load average was off by up to the number of CPUs in the machine. As a consequence, job scheduling worked improperly causing a drop in the system performance. This update keeps the delta of the CPU going into NO_HZ idle separately, and folds the pending idle delta into the global active countwhile correctly aging the averages for the idle-duration when leaving NO_HZ mode. Now, job scheduling works correctly, ensuring balanced CPU load. (BZ#1300349)" From: https://rhn.redhat.com/errata/RHSA-2016-0494.htm...

More goo from hrtimers integration. We do compile and run properly with NO_HZ enabled. There was a period when we didn't because of a missing export, but that was since fixed. And with the clocksource code now firmly in place, we can get rid of code that fixes up the wallclock, since this is done in the common infrastructure. This actually fixes a timer bug as well, th...

More goo from hrtimers integration. We do compile and run properly with NO_HZ enabled. There was a period when we didn't because of a missing export, but that was since fixed. And with the clocksource code now firmly in place, we can get rid of code that fixes up the wallclock, since this is done in the common infrastructure. This actually fixes a timer bug as well, th...

Hi, After switching to the 2.6.32-573.22.1.el6.x86_64 kernel (CentOS 6) a few weeks ago I have noticed that my servers are now reporting a much higher idle load. The servers are being monitored with Zabbix, and there is a clear difference between the older kernel 2.6.32-573.12.1 and the newer 2.6.32-573.12.1. I can see the problem on both physical and virtual servers. You can see the Load

...I think this may be a process accounting bug. If interrupts are disabled for a considerable amount of time ( say multiple ticks), the process accounting code will still account a single tick for such cases, on the next interrupt tick. Shouldn't we have some way to fix that case like we do for NO_HZ restart_sched_tick case, where we account for multiple idle ticks. IOW, doesn't process accounting need to account for these cases when interrupts are disabled for more than one tick period? I stumbled across this while trying to find a solution to figure out the amount of stolen time from L...

...I think this may be a process accounting bug. If interrupts are disabled for a considerable amount of time ( say multiple ticks), the process accounting code will still account a single tick for such cases, on the next interrupt tick. Shouldn't we have some way to fix that case like we do for NO_HZ restart_sched_tick case, where we account for multiple idle ticks. IOW, doesn't process accounting need to account for these cases when interrupts are disabled for more than one tick period? I stumbled across this while trying to find a solution to figure out the amount of stolen time from L...

Hi all :) I''ve tested this and having a cpufreq that slows down the CPU affects the rate of HTB. My ondemand cpufreq governor scales down the CPU frequency about 40% and this is more or less the slowdown the rate suffers, 40%. Any known way of dealing with this without having to disable cpufreq? Thanks in advance :) Ra?l N??ez de Arenas Coronado -- Linux Registered

...d that just is ugly. Some VMI fixes; we support COMPAT_VDSO now that the relocation code is there, re-add the lazy MMU fix now that Jeremy's cleanups have been applied to -mm, implement kmap_atomic_pte. Next, re-implement the VMI timer, dropping all the NO_IDLE_HZ code, making it dependent on NO_HZ and using the proper clockevents infrastructure. I am looking for feedback on this, but it works and applies as is, and is certainly better and cleaner than the existing code. Hopefully I have taken as many fingers out of the APIC pie as possible. Finally, fix the BusLogic driver to use request_...

...d that just is ugly. Some VMI fixes; we support COMPAT_VDSO now that the relocation code is there, re-add the lazy MMU fix now that Jeremy's cleanups have been applied to -mm, implement kmap_atomic_pte. Next, re-implement the VMI timer, dropping all the NO_IDLE_HZ code, making it dependent on NO_HZ and using the proper clockevents infrastructure. I am looking for feedback on this, but it works and applies as is, and is certainly better and cleaner than the existing code. Hopefully I have taken as many fingers out of the APIC pie as possible. Finally, fix the BusLogic driver to use request_...

Lguest currently requires a TSC, which breaks older machines and Matt Mackall who boots the host with "notsc". In addition, there is no good solution to changing TSC speeds (informing all the guests about the TSC impending change before it happens would be a great deal of code and have issues with disobedient guests). This patch makes the host determine if the TSC is both constant and

Lguest currently requires a TSC, which breaks older machines and Matt Mackall who boots the host with "notsc". In addition, there is no good solution to changing TSC speeds (informing all the guests about the TSC impending change before it happens would be a great deal of code and have issues with disobedient guests). This patch makes the host determine if the TSC is both constant and

Here's couple of patches to improve the softlockup watchdog. The first changes the softlockup timer from using jiffies to sched_clock() as a timebase. Xen and VMI implement sched_clock() as counting unstolen time, so time stolen by the hypervisor won't cause the watchdog to bite. The second adds per-cpu enable flags for the watchdog timer. This allows the timer to be disabled when the