On Mon, Jul 29, 2013 at 10:58:40AM +0200, Kevin Wolf wrote:
Am 26.07.2013 um 10:43 hat Stefan Hajnoczi geschrieben:
On Thu, Jul 25, 2013 at 07:53:33PM +0100, Alex Bligh wrote:
--On 25 July 2013 14:32:59 +0200 Jan Kiszka jan.kis...@siemens.com
wrote:
I would happily at a
Am 26.07.2013 um 10:43 hat Stefan Hajnoczi geschrieben:
On Thu, Jul 25, 2013 at 07:53:33PM +0100, Alex Bligh wrote:
--On 25 July 2013 14:32:59 +0200 Jan Kiszka jan.kis...@siemens.com wrote:
I would happily at a QEMUClock of each type to AioContext. They are after
all pretty
--On 29 July 2013 10:58:40 +0200 Kevin Wolf kw...@redhat.com wrote:
But considering your first paragraph, why is it safe to let block jobs
running while we're migrating? Do we really do that? It sounds unsafe to
me.
If I remember right, the sending end now does the bdrv_close before
the
Il 29/07/2013 10:58, Kevin Wolf ha scritto:
Am 26.07.2013 um 10:43 hat Stefan Hajnoczi geschrieben:
On Thu, Jul 25, 2013 at 07:53:33PM +0100, Alex Bligh wrote:
--On 25 July 2013 14:32:59 +0200 Jan Kiszka jan.kis...@siemens.com wrote:
I would happily at a QEMUClock of each type to
On Thu, Jul 25, 2013 at 07:53:33PM +0100, Alex Bligh wrote:
--On 25 July 2013 14:32:59 +0200 Jan Kiszka jan.kis...@siemens.com wrote:
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
--On 26 July 2013 10:43:45 +0200 Stefan Hajnoczi stefa...@gmail.com wrote:
block.c and block/qed.c use vm_clock because block drivers should not do
guest I/O while the vm is stopped. This is especially true during live
migration where it's important to hand off the image file from the
source
Il 26/07/2013 11:08, Alex Bligh ha scritto:
--On 26 July 2013 10:43:45 +0200 Stefan Hajnoczi stefa...@gmail.com
wrote:
block.c and block/qed.c use vm_clock because block drivers should not do
guest I/O while the vm is stopped. This is especially true during live
migration where it's
On 2013-07-25 20:53, Alex Bligh wrote:
--On 25 July 2013 14:32:59 +0200 Jan Kiszka jan.kis...@siemens.com wrote:
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
Jan,
--On 26 July 2013 12:05:06 +0200 Jan Kiszka jan.kis...@siemens.com wrote:
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
On Tue, Jul 23, 2013 at 10:51:06AM +0800, liu ping fan wrote:
On Mon, Jul 22, 2013 at 2:28 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-07-22 06:38, liu ping fan wrote:
On Sun, Jul 21, 2013 at 5:53 PM, Alex Bligh a...@alex.org.uk wrote:
Liu,
--On 21 July 2013 16:42:57 +0800
On Mon, Jul 22, 2013 at 06:18:03PM +0800, liu ping fan wrote:
On Mon, Jul 22, 2013 at 5:40 PM, Alex Bligh a...@alex.org.uk wrote:
Liu,
--On 22 July 2013 12:38:02 +0800 liu ping fan qemul...@gmail.com wrote:
I read your second series, and try to summary the main different between
us.
On 2013-07-25 13:44, Stefan Hajnoczi wrote:
On Tue, Jul 23, 2013 at 10:51:06AM +0800, liu ping fan wrote:
On Mon, Jul 22, 2013 at 2:28 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-07-22 06:38, liu ping fan wrote:
On Sun, Jul 21, 2013 at 5:53 PM, Alex Bligh a...@alex.org.uk wrote:
Liu,
On Sun, Jul 21, 2013 at 04:42:57PM +0800, Liu Ping Fan wrote:
Currently, the timers run on iothread within BQL, so virtio-block dataplane
can not use throttle,
as Stefan Hajnoczi pointed out in his patches to port dataplane onto block
layer.(Thanks, Stefan)
To enable this feature, I plan to
--On 25 July 2013 14:05:30 +0200 Stefan Hajnoczi stefa...@gmail.com 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
On 2013-07-25 14:21, Alex Bligh wrote:
--On 25 July 2013 14:05:30 +0200 Stefan Hajnoczi stefa...@gmail.com
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
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 stefa...@gmail.com
wrote:
Alex Bligh's series gives each AioContext its own rt_clock. This avoids
the need for synchronization in the simple case. If we
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 stefa...@gmail.com
wrote:
Alex Bligh's series gives each AioContext its own rt_clock. This avoids
the need for
On Thu, Jul 25, 2013 at 2:38 PM, Jan Kiszka jan.kis...@siemens.com wrote:
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 stefa...@gmail.com
wrote:
Alex Bligh's
On 2013-07-25 14:41, Stefan Hajnoczi wrote:
On Thu, Jul 25, 2013 at 2:38 PM, Jan Kiszka jan.kis...@siemens.com wrote:
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
Il 25/07/2013 14:38, Jan Kiszka ha scritto:
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 stefa...@gmail.com
wrote:
Alex Bligh's series gives each AioContext its
On 2013-07-25 15:02, Paolo Bonzini wrote:
Il 25/07/2013 14:48, Jan Kiszka ha scritto:
The concept of clocks (with start/stop property) and active timers shall
not be mixed, they are independent.
Are you referring to this in particular:
void pause_all_vcpus(void)
{
CPUState *cpu =
Il 25/07/2013 14:48, Jan Kiszka ha scritto:
The concept of clocks (with start/stop property) and active timers shall
not be mixed, they are independent.
Are you referring to this in particular:
void pause_all_vcpus(void)
{
CPUState *cpu = first_cpu;
qemu_clock_enable(vm_clock,
On Thu, Jul 25, 2013 at 3:06 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-07-25 15:02, Paolo Bonzini wrote:
Il 25/07/2013 14:48, Jan Kiszka ha scritto:
The concept of clocks (with start/stop property) and active timers shall
not be mixed, they are independent.
Are you referring to
On 2013-07-25 15:31, Stefan Hajnoczi wrote:
On Thu, Jul 25, 2013 at 3:06 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-07-25 15:02, Paolo Bonzini wrote:
Il 25/07/2013 14:48, Jan Kiszka ha scritto:
The concept of clocks (with start/stop property) and active timers shall
not be mixed,
--On 25 July 2013 14:32:59 +0200 Jan Kiszka jan.kis...@siemens.com wrote:
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
Il 24/07/2013 03:28, liu ping fan ha scritto:
On Tue, Jul 23, 2013 at 6:30 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 23/07/2013 04:53, liu ping fan ha scritto:
The scenior I can figure out is if adopting timeout of poll, then when
changing the deadline, we need to invoke poll, and set
--On 24 July 2013 08:42:26 +0200 Paolo Bonzini pbonz...@redhat.com wrote:
With ppoll, is this true or just hearsay?
(Without ppoll, indeed setitimer has 1 us resolution while poll has 1
ms; too bad that select has other problems, because select has also 1 us
resolution).
Most 'reasonable'
Il 24/07/2013 09:31, Alex Bligh ha scritto:
--On 24 July 2013 08:42:26 +0200 Paolo Bonzini pbonz...@redhat.com wrote:
With ppoll, is this true or just hearsay?
(Without ppoll, indeed setitimer has 1 us resolution while poll has 1
ms; too bad that select has other problems, because
On Wed, Jul 24, 2013 at 2:42 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 24/07/2013 03:28, liu ping fan ha scritto:
On Tue, Jul 23, 2013 at 6:30 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 23/07/2013 04:53, liu ping fan ha scritto:
The scenior I can figure out is if adopting timeout
Il 24/07/2013 09:43, liu ping fan ha scritto:
Paid some time to dig the kernel code, and find out that the
resolution lost by timeout of poll/select..etc is cause by the timeout
is a slack region.
See code in
do_poll()
if (!poll_schedule_timeout(wait, TASK_INTERRUPTIBLE, to, slack))
Paolo,
--On 24 July 2013 09:43:28 +0200 Paolo Bonzini pbonz...@redhat.com wrote:
Most 'reasonable' POSIX compliant operating systems have ppoll
Really? I could find no manpages for any of Solaris and *BSD.
OK I shall (re)research that then! I suppose select() / pselect() is
an alternative
Paolo,
--On 24 July 2013 09:54:57 +0200 Paolo Bonzini pbonz...@redhat.com wrote:
Alex, can you add it to your series? (Note that you must set a timer
slack of 1, because 0 is interpreted as default).
Sure, will do. I'm guessing I'll have to look for that inside configure
as well.
--
Alex
Il 24/07/2013 10:01, Alex Bligh ha scritto:
Part of it should be fixed by os_setup_early_signal_handling.
This is corroborated by the fact that without
os_setup_early_signal_handling Wine always works, and Windows breaks.
This:
http://www.windowstimestamp.com/description
suggests that
[...]
http://social.msdn.microsoft.com/Forums/vstudio/en-US/e8a7cb1e-9edd-4ee3-982e-f66b7bf6ae44/improve-accuracy-waitforsingleobject
suggest that WaitFor{Single,Multiple}Objects can have pretty
appalling latency anyway (100ms!), and there's no evidence that's
limited by making one of the FDs
--On 24 July 2013 09:01:22 +0100 Alex Bligh a...@alex.org.uk wrote:
Most 'reasonable' POSIX compliant operating systems have ppoll
Really? I could find no manpages for any of Solaris and *BSD.
OK I shall (re)research that then! I suppose select() / pselect() is
an alternative when there
Il 24/07/2013 10:37, Alex Bligh ha scritto:
--On 24 July 2013 09:01:22 +0100 Alex Bligh a...@alex.org.uk wrote:
Most 'reasonable' POSIX compliant operating systems have ppoll
Really? I could find no manpages for any of Solaris and *BSD.
OK I shall (re)research that then! I suppose
Il 23/07/2013 04:53, liu ping fan ha scritto:
The scenior I can figure out is if adopting timeout of poll, then when
changing the deadline, we need to invoke poll, and set the new
timeout, right?
Yes, you need to call aio_notify so that poll is reinvoked.
Paolo
--On 23 July 2013 10:53:26 +0800 liu ping fan qemul...@gmail.com wrote:
Firstly, I can't see the advantage of keeping the alarm_timer stuff
around at all if we can delete it. Save, of course, that on systems
that don't have ppoll or equivalent you lose sub-millisecond timing by
deleting them.
On Tue, Jul 23, 2013 at 6:30 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 23/07/2013 04:53, liu ping fan ha scritto:
The scenior I can figure out is if adopting timeout of poll, then when
changing the deadline, we need to invoke poll, and set the new
timeout, right?
Yes, you need to call
On Mon, Jul 22, 2013 at 2:28 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-07-22 06:38, liu ping fan wrote:
On Sun, Jul 21, 2013 at 5:53 PM, Alex Bligh a...@alex.org.uk wrote:
Liu,
--On 21 July 2013 16:42:57 +0800 Liu Ping Fan qemul...@gmail.com wrote:
Currently, the timers run on
On Mon, Jul 22, 2013 at 6:18 PM, liu ping fan qemul...@gmail.com wrote:
On Mon, Jul 22, 2013 at 5:40 PM, Alex Bligh a...@alex.org.uk wrote:
Liu,
--On 22 July 2013 12:38:02 +0800 liu ping fan qemul...@gmail.com wrote:
I read your second series, and try to summary the main different between
On 2013-07-22 06:38, liu ping fan wrote:
On Sun, Jul 21, 2013 at 5:53 PM, Alex Bligh a...@alex.org.uk wrote:
Liu,
--On 21 July 2013 16:42:57 +0800 Liu Ping Fan qemul...@gmail.com wrote:
Currently, the timers run on iothread within BQL, so virtio-block
dataplane can not use throttle, as
Liu,
--On 22 July 2013 12:38:02 +0800 liu ping fan qemul...@gmail.com wrote:
I read your second series, and try to summary the main different between
us. Please correct me, if I misunderstood something.
--1st. You try to create a separate QemuClock for AioContext.
I think QemuClock is the
On Mon, Jul 22, 2013 at 5:40 PM, Alex Bligh a...@alex.org.uk wrote:
Liu,
--On 22 July 2013 12:38:02 +0800 liu ping fan qemul...@gmail.com wrote:
I read your second series, and try to summary the main different between
us. Please correct me, if I misunderstood something.
--1st. You try to
Currently, the timers run on iothread within BQL, so virtio-block dataplane can
not use throttle,
as Stefan Hajnoczi pointed out in his patches to port dataplane onto block
layer.(Thanks, Stefan)
To enable this feature, I plan to enable timers to run on AioContext's thread.
And maybe in future,
Liu,
--On 21 July 2013 16:42:57 +0800 Liu Ping Fan qemul...@gmail.com wrote:
Currently, the timers run on iothread within BQL, so virtio-block
dataplane can not use throttle, as Stefan Hajnoczi pointed out in his
patches to port dataplane onto block layer.(Thanks, Stefan) To enable
this
On Sun, Jul 21, 2013 at 5:53 PM, Alex Bligh a...@alex.org.uk wrote:
Liu,
--On 21 July 2013 16:42:57 +0800 Liu Ping Fan qemul...@gmail.com wrote:
Currently, the timers run on iothread within BQL, so virtio-block
dataplane can not use throttle, as Stefan Hajnoczi pointed out in his
patches
47 matches
Mail list logo
