[Qemu-block] [PATCH v2] Introduce attributes to qemu timer subsystem

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 (as

[Qemu-block] [PATCH v2 2/4] Introduce attributes to qemu timer subsystem

'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 --- Not

Re: [Qemu-block] [PATCH v2 2/4] Introduce attributes to qemu timer subsystem

> 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 actuall

Re: [Qemu-block] [PATCH v2 2/4] Introduce attributes to qemu timer subsystem

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 Q

Re: [Qemu-block] [PATCH v2 2/4] Introduce attributes to qemu timer subsystem

>ср, 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

[Qemu-block] [PATCH v3 2/4] Introduce attributes to qemu timer subsystem

(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

[Qemu-block] backend for blk or fs with guaranteed blocking/synchronous I/O

is always same. Actually, what 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 -- С уважением, Артем Писаренко

Re: [Qemu-block] backend for blk or fs with guaranteed blocking/synchronous I/O

7;t required to be persistent and stay on host during execution of containers. 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: &

Re: [Qemu-block] backend for blk or fs with guaranteed blocking/synchronous I/O

MB/s 55,9 MB/s 54,1 MB/s 56,0 MB/s Example runs on my tiny linux 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

[Qemu-block] [PATCH 2/3] Introduce attributes to qemu timer subsystem

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