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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list