On 10/28/2018 03:50 PM, Paolo Bonzini wrote:
On 27/10/2018 01:33, Emilio G. Cota wrote:
On Wed, Oct 17, 2018 at 12:10:15 +0200, Paolo Bonzini wrote:
On 16/10/2018 13:10, guangrong.x...@gmail.com wrote:
An idea: the total number of requests is going to be very small, and a
PtrRing is not
On 27/10/2018 01:33, Emilio G. Cota wrote:
> On Wed, Oct 17, 2018 at 12:10:15 +0200, Paolo Bonzini wrote:
>> On 16/10/2018 13:10, guangrong.x...@gmail.com wrote:
>
>> An idea: the total number of requests is going to be very small, and a
>> PtrRing is not the nicest data structure for multiple
On Wed, Oct 17, 2018 at 12:10:15 +0200, Paolo Bonzini wrote:
> On 16/10/2018 13:10, guangrong.x...@gmail.com wrote:
> An idea: the total number of requests is going to be very small, and a
> PtrRing is not the nicest data structure for multiple producer/single
> consumer. So you could instead:
On 18/10/2018 11:30, Xiao Guangrong wrote:
> Beside that... i think we get the chance to remove ptr_ring gracefully,
> as the bitmap can indicate the ownership of the request as well. If
> the bit is 1 (supposing all bits are 1 on default), only the user can
> operate it, the bit will be cleared
On 10/17/2018 06:10 PM, Paolo Bonzini wrote:
An idea: the total number of requests is going to be very small, and a
PtrRing is not the nicest data structure for multiple producer/single
consumer. So you could instead:
- add the size of one request to the ops structure. Move the
On 16/10/2018 13:10, guangrong.x...@gmail.com wrote:
> From: Xiao Guangrong
>
> Current implementation of compression and decompression are very
> hard to be enabled on productions. We noticed that too many wait-wakes
> go to kernel space and CPU usages are very low even if the system
> is
