Re: [libvirt] [PATCH 00/18] Re-arrange the way cgroups are setup
On Thu, Apr 04, 2013 at 06:38:29PM +0200, Viktor Mihajlovski wrote:
On 04/04/2013 03:40 PM, Daniel P. Berrange wrote:
> /sys/fs/cgroup
> ├── cpu,cpuacct
> │ ├── libvirt
> │ │ ├── lxc
> │ │ │ └── busy
> │ │ └── qemu
> │ │ └── vm1
> │ │ ├── emulator
> │ │ └── vcpu0
It's somehow off-topic but if you do a rework you might also consider a
conceptual change wrt to $domain/emulator and $domain/vcpu* ...
Just today I was confronted with a race in
qemuSetupCgroupForEmulator/virCgroupMoveTask on highly utilized system.
The problem is that if a QEMU thread terminates during the move from
$domain/tasks to $domain/emulator/tasks the virCgroupAddTaskController
call will fail resulting in a failure to start the domain.
Another possible issue is that if new QEMU threads are spawned after
the virCgroupGetValueStr call they will not be moved.
This seems easy enough to fix. Instead of starting in $domain/ and
moving them to $domain/emulator, we should just start QEMU in the
$domain/emulator directory right away.
So, since the threads in $domain/tasks are 'hypervisor'
threads anyway,
shouldn't we get rid of the emulator directory altogether?
The problem is that any controls you apply at the $domain/ level,
will also affect the $domain/vcpuNN levels. To get controls that
are guaranteed to only affect the emulator threads, you need them
to be in a directory that is parallel to the vcpuN directories,
not a parent of them.
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|