(new
'attribute' argument added, timer_list replaced with timer_list_group+type
combinations, comments improved to avoid info duplication).
Also existing aio interface extended with attribute-enabled variants of
functions, which create/initialize timers.
Signed-off-by: Artem Pisarenko
---
Notes
>ср, 17 окт. 2018 г. в 20:43, Paolo Bonzini:
>On 17/10/2018 15:07, Artem Pisarenko wrote:
>> Yes, but without words ..."when they fire" in attributes comments.
>
> For now the only attribute applies when timers fire; that sentence was a
> way to clarify the inte
Yes, but without words ..."when they fire" in attributes comments.
ср, 17 окт. 2018 г. в 17:24, Paolo Bonzini :
> On 17/10/2018 12:57, Artem Pisarenko wrote:
> >> Further down in this patch the notation is QEMU_TIMER_ATTR_, which I
> >> think is clearer because
> Further down in this patch the notation is QEMU_TIMER_ATTR_, which I
> think is clearer because QEMU_TIMER_ATTR(id) looks like a (non-existent)
> macro. Please use the QEMU_TIMER_ATTR_ notation consistently.
Yes, I've just forgot to update comments after previous patch version,
where it
'attribute' argument added, timer_list replaced with timer_list_group+type
combinations, comments improved to avoid info duplication).
Also existing aio interface extended with attribute-enabled variants of
functions, which create/initialize timers.
Signed-off-by: Artem Pisarenko
---
Notes:
v2
improved to avoid info duplication.
Also existing aio interface extended with attribute-enabled variants of
functions, which create/initialize timers.
Signed-off-by: Artem Pisarenko
---
Notes:
v2:
- timer creation/initialize functions reworked and and their unnecessary
variants removed
variants of functions, which create/initialize timers.
Signed-off-by: Artem Pisarenko
---
Notes:
Conversion and association between QEMUTimerAttrBit and accessor macro are
dumb.
Maybe better alternatives exist (like QFlags in Qt framework) or existing
qemu code may be reused, if any
ux x86_64 guest (strange results):
root@guest:~# ./test.sh 1
17.5 MB/s
root@guest:~# ./test.sh 10
3.2 MB/s
2.7 MB/s
2.6 MB/s
2.0 MB/s
2.0 MB/s
1.9 MB/s
1.8 MB/s
1.8 MB/s
1.8 MB/s
1.8 MB/s
Please, explain these results. Or maybe I wrong and it's normal ?
чт, 6 сент. 2018 г
tainers. They may be
transferred to guest RAM before execution. They're just source images of
rootfs.
чт, 6 сент. 2018 г. в 21:08, Michael S. Tsirkin :
> On Thu, Sep 06, 2018 at 04:24:12PM +0600, Artem Pisarenko wrote:
> > Hi all,
> >
> > I'm developing paravirtualized target
I'm trying to achieve have direct contradiction with most
people trying to avoid, because synchronous I/O degradates performance in
vast majority of usage scenarios.
Does anyone have any thoughts on this?
Best regards,
Artem Pisarenko
--
С уважением,
Артем Писаренко
10 matches
Mail list logo