similar to: Xen and tickless Linux

Greetings- I'm running some USB DAHDI hardware on a system with a tickless kernel. The audio quality is quite poor. Could the tickless kernel be to blame? If so, when recompiling a kernel that is *not* tickless, is there a recommended KERNEL_HZ value? IIRC, older kernels used to be 1000, but newer ones are 250. Thoughts? --Tim

Hello everyone, I''ve always wondered - would dom0 be better off with a tickless kernel or not? In other words, can someone explain which choice to make with regards to CONFIG_NO_HZ? -- Stay in touch, Mark van Dijk. ,-------------------------------- ----------------------------'' Mon Aug 06 15:40 UTC 2012 Today is Pungenday, the 72nd day of Confusion in the

Hi, tinc has a fixed timeout of 1 second for select() in the main loop. I think this could be improved. Do you think the following patch goes into the right direction ? I don't know whether pselect() is standard enough (works under "current" linux, however I don't know about the other arches). Maybe a config option is necessary. It's probably possible

On Wed, Jun 17, 2020 at 01:31:57PM +0200, Michal Hocko wrote: > On Wed 17-06-20 04:08:20, Matthew Wilcox wrote: > > If you call vfree() under > > a spinlock, you're in trouble. in_atomic() only knows if we hold a > > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic() > > in __vfree(). So we need the warning in order that preempt people can

Currently, if you are running CentOS-4.x on a Vmware box you end up with time skew problems. The main fix has been using a set of recompiled kernel that has a HZ that is more fitting with what Vmware expects (eg 100 hz). The 4.7 kernels look like they will not need this: http://jons-thoughts.blogspot.com/2008/04/rhel-and-vmware-time-skew-problems.html Well, I've gotten quite the number of

Jeremy Fitzhardinge wrote: > Andrew Morton wrote: > > On Thu, 15 Feb 2007 22:14:45 -0800 Dan Hecht > <dhecht@vmware.com> wrote: > > > > > >>> config PREEMPT > >>> bool "Preemptible Kernel (Low-Latency Desktop)" > >>> + depends on !XEN > >>> help > >>> This option reduces the latency of

Jeremy Fitzhardinge wrote: > Andrew Morton wrote: > > On Thu, 15 Feb 2007 22:14:45 -0800 Dan Hecht > <dhecht@vmware.com> wrote: > > > > > >>> config PREEMPT > >>> bool "Preemptible Kernel (Low-Latency Desktop)" > >>> + depends on !XEN > >>> help > >>> This option reduces the latency of

Jeremy Fitzhardinge wrote: > Andrew Morton wrote: > > On Thu, 15 Feb 2007 22:14:45 -0800 Dan Hecht > <dhecht@vmware.com> wrote: > > > > > >>> config PREEMPT > >>> bool "Preemptible Kernel (Low-Latency Desktop)" > >>> + depends on !XEN > >>> help > >>> This option reduces the latency of

Hi, I'm building a test asterisk server and building the latest kernel I got to wonder if there are any specific recommendations about schedulers and so forth for optimum performance. There are a few areas that raise questions in my mind and I wonder if anyone has any opinions/comments on which settings are most suitable for use with asterisk: SLAB Allocator (SLAB or SLUB?) Tickless

Hi! As dom0 I''m running Ubuntu Hardy withe xen 3.3 from backports. Reason to using xen 3.3 is that I could get Intrepid stock kernel to work as domu with xen 3.2. Now the problem I have is that I can''t passthrough PCI-devices to my domu. If I run lspci in the domu nothing is returned. I''ve tried to use the kernel from Hardy (2.6.24-21-xen) and stock kernel from

On 03/01/16 21:11, H. Peter Anvin via Syslinux wrote: > On 03/01/16 07:21, Patrick Masotta via Syslinux wrote: >> >> At the moment I'm seeing timing issues on TFTP transfers (lwIP depends >> on the new interrupt based timer). I have consistently detected >> >> multiple Requests, double ACKs, etc. All these problems seem to be >> >> sourced on the

----- Forwarded message from Jeremy Fitzhardinge <jeremy at goop.org> ----- From: Jeremy Fitzhardinge <jeremy at goop.org> To: Xen-devel <xen-devel at lists.xensource.com>, xen-users at lists.xensource.com, Virtualization Mailing List <virtualization at lists.osdl.org> Cc: Date: Wed, 30 Jul 2008 17:51:37 -0700 Subject: [Xen-devel] State of Xen in upstream Linux Well,

On Wed 17-06-20 04:08:20, Matthew Wilcox wrote: > On Wed, Jun 17, 2020 at 09:12:12AM +0200, Michal Hocko wrote: > > On Tue 16-06-20 17:37:11, Matthew Wilcox wrote: > > > Not just performance critical, but correctness critical. Since kvfree() > > > may allocate from the vmalloc allocator, I really think that kvfree() > > > should assert that it's

On Wed 17-06-20 04:08:20, Matthew Wilcox wrote: > On Wed, Jun 17, 2020 at 09:12:12AM +0200, Michal Hocko wrote: > > On Tue 16-06-20 17:37:11, Matthew Wilcox wrote: > > > Not just performance critical, but correctness critical. Since kvfree() > > > may allocate from the vmalloc allocator, I really think that kvfree() > > > should assert that it's

Hello all, My machine is a dual xeon x5520 server with NUMA support. I have some question about xen dom0 kernel. Since xen hypervisor has provided vcpu schedule, do we need to compile the following feature in dom0 kernel? - Tickless System (Dynamic Ticks) - High Resolution Timer Support - AMD IOMMU support - SMT (Hyperthreading) scheduler support - Multi-core scheduler suppor

> > There are quite a few; primarily we simply cannot make lwIP > (lpxelinux.0) work without it. However, pxelinux.0 should not depend on > this. I'm finding most of the problems on lpxelinux.0 > >Now, tickful timekeeping is wasteful, but this is a bootloader, and >functionality is the main concern. The "tickless" version still >depended on the BIOS

i386 Transparent paravirtualization patch #1. Add support for interrupt holdoff to the entry.S fault and syscall paths. This is a straightforward macro-ization for the default sub-architecture. Note that CLI, STI and IRET may be called with non-flat segments because guest %ds and %es segments are live at the time. Any alternative implementation (such as a virtual interrupt mask) is required to

i386 Transparent paravirtualization patch #1. Add support for interrupt holdoff to the entry.S fault and syscall paths. This is a straightforward macro-ization for the default sub-architecture. Note that CLI, STI and IRET may be called with non-flat segments because guest %ds and %es segments are live at the time. Any alternative implementation (such as a virtual interrupt mask) is required to

Hi List! I installed Asterisk 1.0.3 stable on a RHEL rebuild. Due to problems with * modules refusing to build I replaced the RHEL kernel with stock 2.6.10. Asterisk seems to be working but when I dial voicemail I hear nothing. When I hangup I see a message on the console that the calller did not specify a mailbox number so I guess voicemail app is working. The phone(Grandstream BT100) is