search for: sched_fifo

...eduling if >enabled (default is yes) which may or may not fail, but if root is used what ices does is mostly irrelevant to JACK. the thread that handles audio processing is created by JACK, and that thread does not inherit any scheduling parameters from its parent. whether other ices thread run SCHED_FIFO is besides the point, and probably should be discouraged. >that user, and therefore _NOT_ run as root anymore. This has been a >common approach for unix apps. yes, but running with SCHED_FIFO and calling mlockall has not been a common approach for unix apps. and because unix systems have ma...

...efault is yes) which may or may not fail, but if root is used > > what ices does is mostly irrelevant to JACK. the thread that handles > audio processing is created by JACK, and that thread does not inherit > any scheduling parameters from its parent. whether other ices thread > run SCHED_FIFO is besides the point, and probably should be discouraged. There are still timing/latency considerations with ices and not just for things relating to JACK. > >that user, and therefore _NOT_ run as root anymore. This has been a > >common approach for unix apps. > > yes, but runn...

We've been using libvirt based containers under CentOS 7 and everything has been working fine. One application we run in our containers is ctdb, which uses SCHED_FIFO (real time) threads. This has been working without problems until our recent upgrade to CentOS 7.3. For some reason, ctdb is no longer able to create real time threads, and I've tried a simple program myself that confirms this. The same program works fine on the hypervisor so I know the ker...

Karl Heyes <karl@xiph.org> writes: > On Mon, 2004-10-18 at 18:27, Jack O'Quin wrote: > > Karl Heyes <karl@xiph.org> writes: > > > > > Are you running with realtime privileges, for this you need to start as > > > root if you want that. Even with realtime privileges there may be odd > > > cases where the scheduling latency is a bit too

Hi I was asking about the fedora 14 kernel if it is good enough for cgroup usage because I am trying to set a cgroup under cpu subsytem ( /dev/cgroup/cpu/group1/ ) that have /cpu.rt_runtime_us of 100000 while cpu.rt_period_us has a value of 1000000 i.e a ratio of 1/10 . still when I run a task (endless loop) in that group (cgexec -g cpu,cpuset:group1 ./test) it gets all the cpu core time

...ted, status=1/FAILURE) Aug 04 10:09:04 pws-01 ctdbd[9031]: CTDB starting on node Aug 04 10:09:04 pws-01 ctdbd[9032]: Starting CTDBD (Version 2.5.4) as PID: 9032 Aug 04 10:09:04 pws-01 ctdbd[9032]: Created PID file /run/ctdb/ctdbd.pid Aug 04 10:09:04 pws-01 ctdbd[9032]: Unable to set scheduler to SCHED_FIFO (Operation not permitted) Aug 04 10:09:04 pws-01 ctdbd[9032]: CTDB daemon shutting down Aug 04 10:09:06 pws-01 ctdbd_wrapper[9023]: CTDB exited during initialisation - check logs. Aug 04 10:09:06 pws-01 systemd[1]: ctdb.service: control process exited, code=exited status=1 Aug 04 10:09:06 pws-01...

Hello, looks like Asterisk (at least the Version 1.4.21.2 from debian lenny, which I use) has a serious Problem with pseudo-realtime mode (-p switch) in conjunction with recent Kernels. Whenn using -p Asterisk simply hangs forever on startup. This is almost certainly related to the CFS SCHED_FIFO changes: http://lwn.net/Articles/296419/ Do you know how a workaround or patch how to run asterisk in pseudo-realtime mode on this Kernels? Everything works fine without using -p! Sven -- "linux is evolution, not intelligent design" (Linus Torvalds) /me is giggls at ircnet, http://s...

...09:04 pws-01 ctdbd[9031]: CTDB starting on node >> Aug 04 10:09:04 pws-01 ctdbd[9032]: Starting CTDBD (Version 2.5.4) as PID: >> 9032 >> Aug 04 10:09:04 pws-01 ctdbd[9032]: Created PID file /run/ctdb/ctdbd.pid >> Aug 04 10:09:04 pws-01 ctdbd[9032]: Unable to set scheduler to SCHED_FIFO >> (Operation not permitted) > your container is dopping sys_nice cap, fix the container config. On > my Fedora LXC host this is done in a global include that is pulled > into all containers by default. I simply gave all caps to the > containers intended for ctdb and then it worke...

...md[1]: Starting CTDB... Aug 04 14:10:37 pws-01 ctdbd[4629]: CTDB starting on node Aug 04 14:10:37 pws-01 ctdbd[4631]: Starting CTDBD (Version 2.5.4) as PID: 4631 Aug 04 14:10:37 pws-01 ctdbd[4631]: Created PID file /run/ctdb/ctdbd.pid Aug 04 14:10:37 pws-01 ctdbd[4631]: Unable to set scheduler to SCHED_FIFO (Operation not permitted) Aug 04 14:10:37 pws-01 ctdbd[4631]: CTDB daemon shutting down Aug 04 14:10:39 pws-01 ctdbd_wrapper[4612]: CTDB exited during initialisation - check logs. Aug 04 14:10:39 pws-01 systemd[1]: ctdb.service: control process exited, code=exited status=1 Aug 04 14:10:39 pws-01...

...4 pws-01 ctdbd[9031]: CTDB starting on node > > Aug 04 10:09:04 pws-01 ctdbd[9032]: Starting CTDBD (Version 2.5.4) as PID: > > 9032 > > Aug 04 10:09:04 pws-01 ctdbd[9032]: Created PID file /run/ctdb/ctdbd.pid > > Aug 04 10:09:04 pws-01 ctdbd[9032]: Unable to set scheduler to SCHED_FIFO > > (Operation not permitted) > > your container is dopping sys_nice cap, fix the container config. Indeed, to make it more concrete, uncomment "lxc.cap.drop = sys_nice" (or so) in /var/lib/lxc/<container>/config. And more caps may occur. > On my Fedora LXC host...

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

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

On Mon, Feb 06, 2017 at 09:32:29AM -0800, Peter Steele wrote: > We've been using libvirt based containers under CentOS 7 and everything has > been working fine. One application we run in our containers is ctdb, which > uses SCHED_FIFO (real time) threads. This has been working without problems > until our recent upgrade to CentOS 7.3. For some reason, ctdb is no longer > able to create real time threads, and I've tried a simple program myself > that confirms this. The same program works fine on the hypervisor so I k...

...> Aug 04 10:09:04 pws-01 ctdbd[9031]: CTDB starting on node > Aug 04 10:09:04 pws-01 ctdbd[9032]: Starting CTDBD (Version 2.5.4) as PID: > 9032 > Aug 04 10:09:04 pws-01 ctdbd[9032]: Created PID file /run/ctdb/ctdbd.pid > Aug 04 10:09:04 pws-01 ctdbd[9032]: Unable to set scheduler to SCHED_FIFO > (Operation not permitted) your container is dopping sys_nice cap, fix the container config. On my Fedora LXC host this is done in a global include that is pulled into all containers by default. I simply gave all caps to the containers intended for ctdb and then it worked just fine. -Ralph -...

Besides playing with Asterisk, i'm also using Linux for all kinds of multimedia things, especially recording music, mixing, etc. In order to use Linux as a digital audio workstation, there are a few things that one must do: use low-latency kernels, use pre-emption, use apps that run with real-time privileges, etc. For example, among audio Linux users, the CK (Con Kolivas) and LCK (Locosoft

...writeable=yes vfs objects= fileid My mount point for gfs-cluster: /dev/drbd0 on /cluster type gfs (rw,hostdata=jid=0:id=589825:first=1) A cut of my log in /var/log/log.ctdb 2010/05/19 15:31:21.784728 [ 5356]: Starting CTDB daemon 2010/05/19 15:31:21.795804 [ 5357]: Set scheduler to SCHED_FIFO 2010/05/19 15:31:21.796078 [ 5357]: tcp/tcp_connect.c:349 Failed to bind() to so cket. Success(0) 2010/05/19 15:31:21.796111 [ 5357]: ctdb chose network address 192.168.134.28:43 79 pnn 0 2010/05/19 15:31:21.796337 [ 5357]: Attached to database '/var/ctdb/persistent/s ecrets.tdb.0' 2010/05/...

...are on the crashing system is: CPU: Intel Xeon E5-2609v2/4x2,5GHz Motherboard: Supermicro X9SRI-F For information, the hardware on non-crashing system is: CPU: Intel XEON L5639/6x2,13 GHz Motherboard: Supermicro X8STi > It seems like the crashes are related to a RT process, even though no > sched_fifo/rr processes are started on this system intentionally. Also, > the > CPU usage is low all the time, no peaks at all. But the kernel reports: > > kernel: [39101.461586] sched: RT throttling activated This is still valid, even though I no longer think that it's related to a RT pro...

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

...tel Xeon E5-2609v2/4x2,5GHz > Motherboard: Supermicro X9SRI-F > > For information, the hardware on non-crashing system is: > CPU: Intel XEON L5639/6x2,13 GHz > Motherboard: Supermicro X8STi > >> It seems like the crashes are related to a RT process, even though no >> sched_fifo/rr processes are started on this system intentionally. >> Also, the >> CPU usage is low all the time, no peaks at all. But the kernel >> reports: >> >> kernel: [39101.461586] sched: RT throttling activated > > This is still valid, even though I no longer thin...