From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2Kp2-0007Nt-3I for qemu-devel@nongnu.org; Thu, 25 Jul 2013 08:39:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2Kp0-0003iV-Ou for qemu-devel@nongnu.org; Thu, 25 Jul 2013 08:39:08 -0400 Received: from david.siemens.de ([192.35.17.14]:33680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2Kp0-0003iQ-Er for qemu-devel@nongnu.org; Thu, 25 Jul 2013 08:39:06 -0400 Message-ID: <51F11C63.40007@siemens.com> Date: Thu, 25 Jul 2013 14:38:59 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1374396185-10870-1-git-send-email-pingfank@linux.vnet.ibm.com> <20130725120530.GJ21033@stefanha-thinkpad.redhat.com> <51F11AFB.9040008@siemens.com> <51F11B94.8090400@redhat.com> In-Reply-To: <51F11B94.8090400@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Alex Bligh , Stefan Hajnoczi , Liu Ping Fan , qemu-devel@nongnu.org, Stefan Hajnoczi , Anthony Liguori On 2013-07-25 14:35, Paolo Bonzini wrote: > Il 25/07/2013 14:32, Jan Kiszka ha scritto: >> On 2013-07-25 14:21, Alex Bligh wrote: >>> >>> >>> --On 25 July 2013 14:05:30 +0200 Stefan Hajnoczi >>> wrote: >>> >>>> Alex Bligh's series gives each AioContext its own rt_clock. This avoids >>>> the need for synchronization in the simple case. If we require timer >>>> access between threads then we really need to synchronize. >>>> >>>> You pointed out in another email that vm_clock stops when the guest is >>>> paused. I think we can find a solution for I/O throttling and QED, >>>> which use vm_clock in the block layer. Note that block jobs already use >>>> rt_clock. >>> >>> I would happily at a QEMUClock of each type to AioContext. They are after >>> all pretty lightweight. >> >> What's the point of adding tones of QEMUClock instances? Considering >> proper abstraction, how are they different for each AioContext? Will >> they run against different clock sources, start/stop at different times? >> If the answer is "they have different timer list", then fix this >> incorrect abstraction. > > s/QEMUClock/QEMUTimerList/ ? :) What do you mean? If the content of struct QEMUClock remained the same, that would just paper over a design mistake. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux