Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 749191 - suspend / resume changes the application defined CPU masks in the cgroups cpuset controller
Summary: suspend / resume changes the application defined CPU masks in the cgroups cpu...
Keywords:
Status: CLOSED DUPLICATE of bug 714271
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-26 12:55 UTC by David Jaša
Modified: 2012-03-20 14:41 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 748885
Environment:
Last Closed: 2012-03-20 14:41:03 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description David Jaša 2011-10-26 12:55:13 UTC
Reproduced on F15, F16 and rawhide"
2.6.40.6-0.fc15.x86_64
3.1.0-1.fc16.x86_64
3.1.0-0.rc10.git0.1.fc17.x86_64

+++ This bug was initially created as a clone of Bug #748885 +++

Description of problem:
cpuset is incorrectly set for libvirt after resume from S3 sleep, causing all vcpus compete on single physical core/thread

Version-Release number of selected component (if applicable):
libcgroup-0.37-3.el6.x86_64

How reproducible:
always

Steps to Reproduce:
0. set up libvirt on multi-core box
1. run:
# cat /cgroup/cpuset{,/libvirt{,/qemu}}/cpuset.cpus ; pm-suspend ; echo resumed ; cat /cgroup/cpuset{,/libvirt{,/qemu}}/cpuset.cpus ; service cgconfig restart ; service libvirtd restart ; sleep 3 ; cat /cgroup/cpuset{,/libvirt{,/qemu}}/cpuset.cpus
  
Actual results:
0-3
0-3
0-3
resumed
0-3
0
0
Stopping cgconfig service:                                 [  OK  ]
Starting cgconfig service:                                 [  OK  ]
Ukončuji démona libvirtd:                                  [  OK  ]
Spouštím libvirtd démona:                                  [  OK  ]
0-3
0-3
0-3

Expected results:
after resume, all files should allow all cores to be used:
[snip]
resumed
0-3
0-3
0-3
[snip]

Additional info:

--- Additional comment from jsafrane on 2011-10-25 16:32:19 CEST ---

Libcgroup does not touch libvirt's cpuset.cpus, these cgroups are managed by libvirt itself.

--- Additional comment from berrange on 2011-10-25 16:39:22 CEST ---

IMHO this looks like a kernel bug. Suspend should be transparent to userspace apps like libvirt. If they have setup a specific cgroups configuration, that configuration should not be changed when the kernel suspends/resumes.

--- Additional comment from djasa on 2011-10-26 01:56:19 CEST ---

Applies to Fedora 15 as well:

# cat /sys/fs/cgroup/cpuset{,/libvirt{,/qemu}}/cpuset.cpus ; pm-suspend ; echo resumed ; cat /sys/fs/cgroup/cpuset{,/libvirt{,/qemu}}/cpuset.cpus ; service cgconfig restart ; service libvirtd restart ; sleep 3 ; cat /sys/fs/cgroup/cpuset{,/libvirt{,/qemu}}/cpuset.cpus ; uname -r
0-3
0-3
0-3
resumed
0-3
0
0
Restarting cgconfig (via systemctl):                       [  OK  ]
Restarting libvirtd (via systemctl):                       [  OK  ]
cat: /sys/fs/cgroup/cpuset/cpuset.cpus: No such file or directory
cat: /sys/fs/cgroup/cpuset/libvirt/cpuset.cpus: No such file or directory
cat: /sys/fs/cgroup/cpuset/libvirt/qemu/cpuset.cpus: No such file or directory

2.6.40.6-0.fc15.x86_64


In addition, Fedora's cgroups don't survive the cgconfig service restart. I'll verify on F16 (and clone the bug if it occurs) in short time too.

--- Additional comment from jsafrane on 2011-10-26 08:36:30 CEST ---

(In reply to comment #3)
> In addition, Fedora's cgroups don't survive the cgconfig service restart. I'll
> verify on F16 (and clone the bug if it occurs) in short time too.

This is expected, we're working on it. Open a new bug, if you wish to track its progress.

Comment 1 David Jaša 2012-03-20 14:41:03 UTC

*** This bug has been marked as a duplicate of bug 714271 ***


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