Bug 687873 - Problems with apps in cgroups trying to set SCHED_FIFO
Summary: Problems with apps in cgroups trying to set SCHED_FIFO
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 15
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-03-15 16:02 UTC by Daniel Walsh
Modified: 2014-06-30 20:00 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-06-04 17:50:13 UTC
Type: ---

Attachments (Terms of Use)
cpu cgroup (546 bytes, text/plain)
2011-03-15 16:02 UTC, Daniel Walsh
no flags Details
memory cgroup (1.51 KB, text/plain)
2011-03-15 16:02 UTC, Daniel Walsh
no flags Details
firefox strace (258.42 KB, text/plain)
2011-03-15 16:03 UTC, Daniel Walsh
no flags Details
evince strace (88.28 KB, text/plain)
2011-03-15 16:03 UTC, Daniel Walsh
no flags Details

Description Daniel Walsh 2011-03-15 16:02:15 UTC
Created attachment 485534 [details]
cpu cgroup

Description of problem:

The sandbox tool can launch and application within a cgroup.  But I am getting errors from firefox and evince when they try to execute 

sched_setscheduler(13401, SCHED_FIFO, { 0 }) = -1 EINVAL (Invalid argument)

GThread-ERROR **: file gthread-posix.c: line 348 (g_thread_create_posix_impl): error 'Invalid argument' during 'pthread_attr_setschedparam (&attr, &sched)'

 cat cgroup 

Comment 1 Daniel Walsh 2011-03-15 16:02:52 UTC
Created attachment 485535 [details]
memory cgroup

Comment 2 Daniel Walsh 2011-03-15 16:03:27 UTC
Created attachment 485536 [details]
firefox strace

Comment 3 Daniel Walsh 2011-03-15 16:03:56 UTC
Created attachment 485537 [details]
evince strace

Comment 4 Daniel Walsh 2011-03-15 16:05:05 UTC
You can see this happening by executing

sandbox -C -W metacity -X xterm

Then execute firefox or evince in the xterm.

If you run 

sandbox -W metacity -X xterm

And run the commands they should work.

Comment 5 Chuck Ebbert 2011-03-17 07:00:48 UTC
Looks like this is happening because we have CONFIG_RT_GROUP_SCHED enabled in our kernel config. Explicit task groups need to have RT bandwidth allocated to them before you can set SCHED_FIFO for their tasks. See Documentation/scheduler/sched-rt-group.txt in the kernel-doc package for how to do it, but after a quick read I think we may just want to disable this feature.

Comment 6 Daniel Walsh 2011-03-17 13:57:30 UTC
So should this be moved to a kernel issue?

Comment 7 Rik van Riel 2011-03-17 14:56:37 UTC
The fundamental issue is, the whole _concepts_ of "share CPU time fairly between these groups" and "run this task with realtime priority" are incompatible with each other.

This is not an implementation issue, but a question of the kernel being asked to fulfill contradictory requirements.

Running a realtime task can only be done in a realtime task group (or outside of the task group system), not in a timeshared task group.

Comment 8 Lennart Poettering 2011-03-17 15:10:55 UTC
For these reasons we are currently not really using the 'cpu' hierarchy in systemd much: if you create a group and want to allow the processes in them get RT scheduling, then you'd have to assign the group RT budget, which is realistically not doable, since we wouldn't know what amount to assign if we did this automatically.

What I'd really like to see is that the rt budget and the non-rt shares could be configured in different hierachies, so that people can set cpu.shares without necessarily implying cpu.rt_runtime_us=0.

Comment 9 Daniel Walsh 2011-03-17 15:42:35 UTC
Is the problem here that the apps are not getting permission denied, which they probably handle but instead are getting EINVAL (Invalid argument), which they don't expect and crash?

Comment 10 Chuck Ebbert 2011-03-20 19:00:41 UTC
I just found bug 442959, which Lennart filed asking us to enable the RT group scheduler, so I don't think we can just disable it to fix of this problem.

Comment 11 Josh Boyer 2011-10-14 14:50:46 UTC
Did anyone come to some kind of resolution for this issue?  We still have CONFIG_RT_GROUP_SCHED=y in the F15 kernel configs and it seems the consensus was that running RT processes in a cgroup without RT budget just wasn't feasible...

Note You need to log in before you can comment on or make changes to this bug.