* Re: [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions
@ 2017-03-03 19:38 Nutaro, James J.
2017-03-03 19:50 ` Frédéric Konrad
2017-03-07 7:03 ` Pavel Dovgalyuk
0 siblings, 2 replies; 9+ messages in thread
From: Nutaro, James J. @ 2017-03-03 19:38 UTC (permalink / raw)
To: 'mttcg@listserver.greensocs.com'; +Cc: 'qemu-devel@nongnu.org'
My original problem seems to stem from something that changed in the way that device emulation and instruction execution interact (I'm guessing). To reproduce the issue, I started a linux image with
qemu-system-i386 -rtc clock=vm -monitor none -icount 1,sleep=off jack.img
After booting, I run
ping localhost
The first round trip time reports look reasonable, being in the millisecond to sub-millisecond range. These occur while the emulator is running slower than real time.
After a bit, the emulator speeds up (skipping over idle periods during I/O?) and the round trip times jump to hundreds of milliseconds, which I had not expected.
If you want to try this experiment yourself, you can get the disk image that I used from here:
http://www.ornl.gov/~1qn/qemu-images/jack.img
Jim
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions
2017-03-03 19:38 [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions Nutaro, James J.
@ 2017-03-03 19:50 ` Frédéric Konrad
2017-03-06 13:08 ` Alex Bennée
2017-03-07 7:03 ` Pavel Dovgalyuk
1 sibling, 1 reply; 9+ messages in thread
From: Frédéric Konrad @ 2017-03-03 19:50 UTC (permalink / raw)
To: Nutaro, James J.
Cc: 'qemu-devel@nongnu.org', Alex Bennée, Paolo Bonzini
Hi Jim,
I think Alex and Paolo worked on an mttcg/icount issue.
Not sure if its related or not.
Fred
On 03/03/2017 08:38 PM, Nutaro, James J. wrote:
> My original problem seems to stem from something that changed in the way that device emulation and instruction execution interact (I'm guessing). To reproduce the issue, I started a linux image with
>
> qemu-system-i386 -rtc clock=vm -monitor none -icount 1,sleep=off jack.img
>
> After booting, I run
>
> ping localhost
>
> The first round trip time reports look reasonable, being in the millisecond to sub-millisecond range. These occur while the emulator is running slower than real time.
>
> After a bit, the emulator speeds up (skipping over idle periods during I/O?) and the round trip times jump to hundreds of milliseconds, which I had not expected.
>
> If you want to try this experiment yourself, you can get the disk image that I used from here:
>
> http://www.ornl.gov/~1qn/qemu-images/jack.img
>
>
> Jim
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions
2017-03-03 19:50 ` Frédéric Konrad
@ 2017-03-06 13:08 ` Alex Bennée
0 siblings, 0 replies; 9+ messages in thread
From: Alex Bennée @ 2017-03-06 13:08 UTC (permalink / raw)
To: Frédéric Konrad
Cc: Nutaro, James J., 'qemu-devel@nongnu.org', Paolo Bonzini
Frédéric Konrad <konrad.frederic@yahoo.fr> writes:
> Hi Jim,
>
> I think Alex and Paolo worked on an mttcg/icount issue.
> Not sure if its related or not.
If you are running a tree post-MTTCG merge you will need to add Paolo's
patches:
Subject: [PATCH 0/6] tcg: fix icount super slowdown
Date: Fri, 3 Mar 2017 14:11:08 +0100
Message-Id: <20170303131113.25898-1-pbonzini@redhat.com>
>
> Fred
>
> On 03/03/2017 08:38 PM, Nutaro, James J. wrote:
>> My original problem seems to stem from something that changed in the way that device emulation and instruction execution interact (I'm guessing). To reproduce the issue, I started a linux image with
>>
>> qemu-system-i386 -rtc clock=vm -monitor none -icount 1,sleep=off jack.img
>>
>> After booting, I run
>>
>> ping localhost
>>
>> The first round trip time reports look reasonable, being in the millisecond to sub-millisecond range. These occur while the emulator is running slower than real time.
>>
>> After a bit, the emulator speeds up (skipping over idle periods during I/O?) and the round trip times jump to hundreds of milliseconds, which I had not expected.
>>
>> If you want to try this experiment yourself, you can get the disk image that I used from here:
>>
>> http://www.ornl.gov/~1qn/qemu-images/jack.img
>>
>>
>> Jim
>>
--
Alex Bennée
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions
2017-03-03 19:38 [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions Nutaro, James J.
2017-03-03 19:50 ` Frédéric Konrad
@ 2017-03-07 7:03 ` Pavel Dovgalyuk
2017-03-13 13:21 ` Alex Bennée
1 sibling, 1 reply; 9+ messages in thread
From: Pavel Dovgalyuk @ 2017-03-07 7:03 UTC (permalink / raw)
To: 'Nutaro, James J.', mttcg, pbonzini; +Cc: qemu-devel
I also encountered icount problems with new MTTCG patches.
Record/replay now cannot work, because iothread requests timers
without kicking the CPU. And cpu thread updates icount (that
are used for the clock).
Therefore invocation of iothread uses incorrect clock and
all virtual timers behave incorrectly.
Record/replay is also broken because current icount is requested
from iothread where current_cpu (and icount progress stored in icount_extra)
is unavailable.
Pavel Dovgalyuk
> -----Original Message-----
> From: mttcg-request@listserver.greensocs.com [mailto:mttcg-request@listserver.greensocs.com]
> On Behalf Of Nutaro, James J.
> Sent: Friday, March 03, 2017 10:39 PM
> To: 'mttcg@listserver.greensocs.com'
> Cc: 'qemu-devel@nongnu.org'
> Subject: RE: -rtc clock=vm with -icount 1,sleep=off introduces unexpected delays in device
> interactions
>
> My original problem seems to stem from something that changed in the way that device emulation
> and instruction execution interact (I'm guessing). To reproduce the issue, I started a linux
> image with
>
> qemu-system-i386 -rtc clock=vm -monitor none -icount 1,sleep=off jack.img
>
> After booting, I run
>
> ping localhost
>
> The first round trip time reports look reasonable, being in the millisecond to sub-millisecond
> range. These occur while the emulator is running slower than real time.
>
> After a bit, the emulator speeds up (skipping over idle periods during I/O?) and the round
> trip times jump to hundreds of milliseconds, which I had not expected.
>
> If you want to try this experiment yourself, you can get the disk image that I used from here:
>
> http://www.ornl.gov/~1qn/qemu-images/jack.img
>
>
> Jim
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions
2017-03-07 7:03 ` Pavel Dovgalyuk
@ 2017-03-13 13:21 ` Alex Bennée
2017-03-14 12:10 ` Pavel Dovgalyuk
0 siblings, 1 reply; 9+ messages in thread
From: Alex Bennée @ 2017-03-13 13:21 UTC (permalink / raw)
To: Pavel Dovgalyuk; +Cc: 'Nutaro, James J.', mttcg, pbonzini, qemu-devel
Pavel Dovgalyuk <dovgaluk@ispras.ru> writes:
> I also encountered icount problems with new MTTCG patches.
>
> Record/replay now cannot work, because iothread requests timers
> without kicking the CPU. And cpu thread updates icount (that
> are used for the clock).
The interaction of kicking the vCPU while grabbing the BQL was a
side-effect. This is now done explicitly for single-threaded emulation
by (6546706d28):
tcg: add kick timer for single-threaded vCPU emulation
> Therefore invocation of iothread uses incorrect clock and
> all virtual timers behave incorrectly.
>
> Record/replay is also broken because current icount is requested
> from iothread where current_cpu (and icount progress stored in icount_extra)
> is unavailable.
I'm working through Paolo's series now but I don't see it as
insurmountable. The aim of keeping current_cpu set only during the
cpu-exec loop was intentional because the system as a whole can't make
assumptions about it always being valid.
>
> Pavel Dovgalyuk
>
>> -----Original Message-----
>> From: mttcg-request@listserver.greensocs.com [mailto:mttcg-request@listserver.greensocs.com]
>> On Behalf Of Nutaro, James J.
>> Sent: Friday, March 03, 2017 10:39 PM
>> To: 'mttcg@listserver.greensocs.com'
>> Cc: 'qemu-devel@nongnu.org'
>> Subject: RE: -rtc clock=vm with -icount 1,sleep=off introduces unexpected delays in device
>> interactions
>>
>> My original problem seems to stem from something that changed in the way that device emulation
>> and instruction execution interact (I'm guessing). To reproduce the issue, I started a linux
>> image with
>>
>> qemu-system-i386 -rtc clock=vm -monitor none -icount 1,sleep=off jack.img
>>
>> After booting, I run
>>
>> ping localhost
>>
>> The first round trip time reports look reasonable, being in the millisecond to sub-millisecond
>> range. These occur while the emulator is running slower than real time.
>>
>> After a bit, the emulator speeds up (skipping over idle periods during I/O?) and the round
>> trip times jump to hundreds of milliseconds, which I had not expected.
>>
>> If you want to try this experiment yourself, you can get the disk image that I used from here:
>>
>> http://www.ornl.gov/~1qn/qemu-images/jack.img
>>
>>
>> Jim
--
Alex Bennée
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions
2017-03-13 13:21 ` Alex Bennée
@ 2017-03-14 12:10 ` Pavel Dovgalyuk
2017-03-14 12:15 ` Paolo Bonzini
0 siblings, 1 reply; 9+ messages in thread
From: Pavel Dovgalyuk @ 2017-03-14 12:10 UTC (permalink / raw)
To: 'Alex Bennée'
Cc: 'Nutaro, James J.', mttcg, pbonzini, qemu-devel
> From: Alex Bennée [mailto:alex.bennee@linaro.org]
> > I also encountered icount problems with new MTTCG patches.
> >
> > Record/replay now cannot work, because iothread requests timers
> > without kicking the CPU. And cpu thread updates icount (that
> > are used for the clock).
>
> The interaction of kicking the vCPU while grabbing the BQL was a
> side-effect. This is now done explicitly for single-threaded emulation
> by (6546706d28):
>
> tcg: add kick timer for single-threaded vCPU emulation
This is not the same.
BQL helped in making execution deterministic - no io and timer
callbacks were performed while CPU is executing.
Now iothread and CPU thread work simultaneously and timers can't
query virtual time correctly, because (if we could query number of executed
instructions) it may have different values on different runs.
I guess you'll have to bring kicking CPU back on iothread invocation
to make execution deterministic in icount mode.
>
> > Therefore invocation of iothread uses incorrect clock and
> > all virtual timers behave incorrectly.
> >
> > Record/replay is also broken because current icount is requested
> > from iothread where current_cpu (and icount progress stored in icount_extra)
> > is unavailable.
>
> I'm working through Paolo's series now but I don't see it as
> insurmountable. The aim of keeping current_cpu set only during the
> cpu-exec loop was intentional because the system as a whole can't make
> assumptions about it always being valid.
Pavel Dovgalyuk
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions
2017-03-14 12:10 ` Pavel Dovgalyuk
@ 2017-03-14 12:15 ` Paolo Bonzini
2017-03-14 12:18 ` Pavel Dovgalyuk
0 siblings, 1 reply; 9+ messages in thread
From: Paolo Bonzini @ 2017-03-14 12:15 UTC (permalink / raw)
To: Pavel Dovgalyuk, 'Alex Bennée'
Cc: 'Nutaro, James J.', mttcg, qemu-devel
On 14/03/2017 13:10, Pavel Dovgalyuk wrote:
> This is not the same.
> BQL helped in making execution deterministic - no io and timer
> callbacks were performed while CPU is executing.
> Now iothread and CPU thread work simultaneously and timers can't
> query virtual time correctly, because (if we could query number of executed
> instructions) it may have different values on different runs.
>
> I guess you'll have to bring kicking CPU back on iothread invocation
> to make execution deterministic in icount mode.
Timers are fixed by my patch. I/O should also work if its effects are
only apparent at given QEMU_CLOCK_VIRTUAL values.
Paolo
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions
2017-03-14 12:15 ` Paolo Bonzini
@ 2017-03-14 12:18 ` Pavel Dovgalyuk
2017-03-14 16:52 ` Paolo Bonzini
0 siblings, 1 reply; 9+ messages in thread
From: Pavel Dovgalyuk @ 2017-03-14 12:18 UTC (permalink / raw)
To: 'Paolo Bonzini', 'Alex Bennée'
Cc: 'Nutaro, James J.', mttcg, qemu-devel
> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> On 14/03/2017 13:10, Pavel Dovgalyuk wrote:
> > This is not the same.
> > BQL helped in making execution deterministic - no io and timer
> > callbacks were performed while CPU is executing.
> > Now iothread and CPU thread work simultaneously and timers can't
> > query virtual time correctly, because (if we could query number of executed
> > instructions) it may have different values on different runs.
> >
> > I guess you'll have to bring kicking CPU back on iothread invocation
> > to make execution deterministic in icount mode.
>
> Timers are fixed by my patch. I/O should also work if its effects are
> only apparent at given QEMU_CLOCK_VIRTUAL values.
Can you point me on that patch?
Pavel Dovgalyuk
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions
2017-03-14 12:18 ` Pavel Dovgalyuk
@ 2017-03-14 16:52 ` Paolo Bonzini
0 siblings, 0 replies; 9+ messages in thread
From: Paolo Bonzini @ 2017-03-14 16:52 UTC (permalink / raw)
To: Pavel Dovgalyuk, 'Alex Bennée'
Cc: 'Nutaro, James J.', mttcg, qemu-devel
On 14/03/2017 13:18, Pavel Dovgalyuk wrote:
>> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
>> On 14/03/2017 13:10, Pavel Dovgalyuk wrote:
>>> This is not the same.
>>> BQL helped in making execution deterministic - no io and timer
>>> callbacks were performed while CPU is executing.
>>> Now iothread and CPU thread work simultaneously and timers can't
>>> query virtual time correctly, because (if we could query number of executed
>>> instructions) it may have different values on different runs.
>>>
>>> I guess you'll have to bring kicking CPU back on iothread invocation
>>> to make execution deterministic in icount mode.
>>
>> Timers are fixed by my patch. I/O should also work if its effects are
>> only apparent at given QEMU_CLOCK_VIRTUAL values.
>
> Can you point me on that patch?
I sent a pull request now, but it doesn't fix record/replay.
https://lists.gnu.org/archive/html/qemu-devel/2017-03/msg02621.html
Paolo
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-03-14 16:52 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-03 19:38 [Qemu-devel] -rtc clock=vm with -icount 1, sleep=off introduces unexpected delays in device interactions Nutaro, James J.
2017-03-03 19:50 ` Frédéric Konrad
2017-03-06 13:08 ` Alex Bennée
2017-03-07 7:03 ` Pavel Dovgalyuk
2017-03-13 13:21 ` Alex Bennée
2017-03-14 12:10 ` Pavel Dovgalyuk
2017-03-14 12:15 ` Paolo Bonzini
2017-03-14 12:18 ` Pavel Dovgalyuk
2017-03-14 16:52 ` Paolo Bonzini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.