From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTzEf-0004Ws-DM for qemu-devel@nongnu.org; Wed, 09 Oct 2013 15:15:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTzEZ-0007x9-8U for qemu-devel@nongnu.org; Wed, 09 Oct 2013 15:15:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37525) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTzEZ-0007wl-0N for qemu-devel@nongnu.org; Wed, 09 Oct 2013 15:15:47 -0400 Message-ID: <5255AB58.3090802@redhat.com> Date: Wed, 09 Oct 2013 21:15:36 +0200 From: Hans de Goede MIME-Version: 1.0 References: <1381259403-7386-1-git-send-email-hdegoede@redhat.com> <52545950.5070403@redhat.com> <52545B44.70005@redhat.com> <28EE4224-856B-4DC1-8159-A0C274BD269E@alex.org.uk> <52546000.6070308@redhat.com> <6CD4D4EE-341E-48D0-98F4-D55C0D3922D4@alex.org.uk> <52546832.9040900@redhat.com> <5254701B.5070804@redhat.com> <525552D9.90407@redhat.com> <2451DF8D-DD3E-4875-B6D6-CEF66A763D7E@alex.org.uk> <52559A8A.2070201@redhat.com> <30CAC247-C396-4991-804B-DD0A0FE68674@alex.org.uk> <5255A554.1070105@redhat.com> <5255A878.7080702@redhat.com> In-Reply-To: <5255A878.7080702@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] main-loop: Don't lock starve io-threads when main_loop_tlg has pending events List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, Alex Bligh Hi, On 10/09/2013 09:03 PM, Paolo Bonzini wrote: > Il 09/10/2013 20:49, Hans de Goede ha scritto: >>> >>> I wonder whether it's meant to be 1 millisecond or 1 microsecond? >> >> Maybe once it was 1 ms, this code just exists to keep the buffers >> of a soundcard filled / emptied in time. 100 times / second is more >> then plenty for that, so that is what I'm going to use in the patch I'm >> about to submit. > > It was 1 ms when that was the resolution of the "alarm tick" (which was > based on /dev/rtc or /dev/hpet), then it became 250 us with "dynamic > ticks", then we know how it became 0 (1 ns after timer_mod is > effectively 0 ns after select). Yep, and the weird thing is, there is a cmdline option to set the wakeup frequency in hz, and parsing code for it, and code to convert it to ticks, it is just not used. So I'm throwing away my initial patch for this and writing a new one. Regards, Hans