Vladimir Sementsov-Ogievskiy writes:
> Hmm. An idea. What we want: read more than one character at a time, as
> it's inefficient. May be instead of modifying monitor_can_read() and
> therefore influence monitor behavior in unpredictable way, we'd better
> add a separate read-cache, and just read
05.03.2021 19:13, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
05.03.2021 17:10, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
24.11.2020 18:44, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
This patch isn't outdated, it applies on master with a little conf
Vladimir Sementsov-Ogievskiy writes:
> 05.03.2021 17:10, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy writes:
>>
>>> 24.11.2020 18:44, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
This patch isn't outdated, it applies on master with a little conflict
atomic_mb_re
05.03.2021 17:10, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
24.11.2020 18:44, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
This patch isn't outdated, it applies on master with a little conflict
atomic_mb_read -> qatomic_mb_read
We have new series "[PATCH v2 0/2] Increase
Vladimir Sementsov-Ogievskiy writes:
> 24.11.2020 18:44, Vladimir Sementsov-Ogievskiy wrote:
>> Hi all!
>>
>> This patch isn't outdated, it applies on master with a little conflict
>> atomic_mb_read -> qatomic_mb_read
>>
>> We have new series "[PATCH v2 0/2] Increase amount of data for monitor
24.11.2020 18:44, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
This patch isn't outdated, it applies on master with a little conflict
atomic_mb_read -> qatomic_mb_read
We have new series "[PATCH v2 0/2] Increase amount of data for monitor to
read", but I do think that we've started from wrong
Hi all!
This patch isn't outdated, it applies on master with a little conflict
atomic_mb_read -> qatomic_mb_read
We have new series "[PATCH v2 0/2] Increase amount of data for monitor to
read", but I do think that we've started from wrong point. And actually we should
start from this old patc
* Markus Armbruster (arm...@redhat.com) wrote:
> Did this fall through the cracks?
>
> Denis Plotnikov writes:
>
> > Right now QMP and HMP monitors read 1 byte at a time from the socket, which
> > is very inefficient. With 100+ VMs on the host this easily reasults in
> > a lot of unnecessary sys
On 7/3/19 9:36 AM, Markus Armbruster wrote:
> Did this fall through the cracks?
>
> Denis Plotnikov writes:
>
>> Right now QMP and HMP monitors read 1 byte at a time from the socket, which
>> is very inefficient. With 100+ VMs on the host this easily reasults in
>> a lot of unnecessary system call
Did this fall through the cracks?
Denis Plotnikov writes:
> Right now QMP and HMP monitors read 1 byte at a time from the socket, which
> is very inefficient. With 100+ VMs on the host this easily reasults in
> a lot of unnecessary system calls and CPU usage in the system.
Yes, reading one byte
Right now QMP and HMP monitors read 1 byte at a time from the socket, which
is very inefficient. With 100+ VMs on the host this easily reasults in
a lot of unnecessary system calls and CPU usage in the system.
This patch changes the amount of data to read to 4096 bytes, which matches
buffer size o
11 matches
Mail list logo
