From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tokarev Subject: Re: KVM: High CPU load with audio enabled Date: Tue, 09 Nov 2010 17:33:34 +0300 Message-ID: <4CD95BBE.5000905@msgid.tls.msk.ru> References: <20101108133310.NDW2tl7gaq4uLMdHXOT0UP@consulting.lsexperts.de> <4CD88C58.9030501@msgid.tls.msk.ru> <4CD905FE.20204@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , Stefan Pietsch , kvm@vger.kernel.org, qemu-devel To: malc Return-path: Received: from isrv.corpit.ru ([86.62.121.231]:38410 "EHLO isrv.corpit.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751320Ab0KIOdg (ORCPT ); Tue, 9 Nov 2010 09:33:36 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 09.11.2010 16:48, malc wrote: > On Tue, 9 Nov 2010, Jan Kiszka wrote: > >> Am 09.11.2010 00:48, Michael Tokarev wrote: [] >>> Yes, sound in 0.13 appears to be broken. It is looping in >>> select/read loop forever, read returns EAGAIN and select >>> says the filedescriptor is ready. >> >> Try to set QEMU_AUDIO_DAC_TRY_POLL=0 for the environment of the qemu >> process. That's long required to get sound out of the Musicpal emulation >> as well (malc, you may recall this). It even got worse with current >> qemu.git: previously, the sounds was just quirky. Now the system is >> booting way slower in polling mode and is partially not reactive anymore. > > Wich driver is being used? ALSA stuff should have been fixed by Jindrich > Makovicka in: > 38cc9b607f85017b095793cab6c129bc9844f441 and > 22d948a2d97434192018bdabaf0a50cda7f994be As far as I can see, both are in 0.13.0 release, which is the one I'm running currently. This is with QEMU_AUDIO_DRV=alsa (default on Debian): ... gettimeofday({1289311843, 426751}, NULL) = 0 select(24, [0 5 13 18 20 23], [], [], {1, 0}) = 1 (in [13], left {0, 999998}) poll([{fd=13, events=POLLIN|POLLERR|POLLNVAL}], 1, 0) = 1 ([{fd=13, revents=POLLIN}]) ioctl(14, 0xc0844123, 0x8e75200) = 0 ioctl(14, 0xc0844123, 0x8e75200) = 0 clock_gettime(CLOCK_MONOTONIC, {654227, 9502215}) = 0 clock_gettime(CLOCK_MONOTONIC, {654227, 9521568}) = 0 gettimeofday({1289311843, 426911}, NULL) = 0 select(24, [0 5 13 18 20 23], [], [], {1, 0}) = 1 (in [13], left {0, 999998}) poll([{fd=13, events=POLLIN|POLLERR|POLLNVAL}], 1, 0) = 1 ([{fd=13, revents=POLLIN}]) ioctl(14, 0xc0844123, 0x8e75200) = 0 ioctl(14, 0xc0844123, 0x8e75200) = 0 clock_gettime(CLOCK_MONOTONIC, {654227, 9660799}) = 0 clock_gettime(CLOCK_MONOTONIC, {654227, 9680088}) = 0 gettimeofday({1289311843, 427070}, NULL) = 0 ... Fd#13 is /dev/snd/timer. For this test, I tried -soundhw ac97. The same happens with es1370 too. With oss or pulseaudio it works just fine. Note that the problem does not occur always. I just booted a win7 guest with ac97, installed a driver, and it whole thing appears to work without this 100% cpu loop, at least after settling down. But several attempts to run a linux guest with es1370 or ac97 results in a reproduceable tight loop - right after bootup. And I just discovered another issue with QUEMU_AUDIO_DRV=pa: when I tried to close sdl window, kvm wents into tight loop waitpid(30478, 0xffa84ccc, 0) = -1 ECHILD (No child processes) waitpid(30478, 0xffa84ccc, 0) = -1 ECHILD (No child processes) waitpid(30478, 0xffa84ccc, 0) = -1 ECHILD (No child processes) waitpid(30478, 0xffa84ccc, 0) = -1 ECHILD (No child processes) waitpid(30478, 0xffa84ccc, 0) = -1 ECHILD (No child processes) waitpid(30478, 0xffa84ccc, 0) = -1 ECHILD (No child processes) waitpid(30478, 0xffa84ccc, 0) = -1 ECHILD (No child processes) ... obviously consuming 100% cpu, and the only way to stop this is to kill it. Unrelated, but also buggy ;) Thanks! /mjt