Il 02/06/2014 15:06, Ming Lei ha scritto:
>
> If you're running SMP under an emulator where exits are expensive, then
> this wins. Under KVM it's marginal at best.
Both my tests on arm64 and x86 are under KVM, and looks the
patch can improve performance a lot. IMO, even though under
KVM, virtio
On 2014-06-01 19:23, Rusty Russell wrote:
Jens Axboe writes:
On 2014-05-30 00:10, Rusty Russell wrote:
Jens Axboe writes:
If Rusty agrees, I'd like to add it for 3.16 with a stable marker.
Really stable? It improves performance, which is nice. But every patch
which goes into the kernel f
On Mon, Jun 2, 2014 at 9:23 AM, Rusty Russell wrote:
> Jens Axboe writes:
>> On 2014-05-30 00:10, Rusty Russell wrote:
>>> Jens Axboe writes:
If Rusty agrees, I'd like to add it for 3.16 with a stable marker.
>>>
>>> Really stable? It improves performance, which is nice. But every patch
>
Jens Axboe writes:
> On 2014-05-30 00:10, Rusty Russell wrote:
>> Jens Axboe writes:
>>> If Rusty agrees, I'd like to add it for 3.16 with a stable marker.
>>
>> Really stable? It improves performance, which is nice. But every patch
>> which goes into the kernel fixes a bug, improves clarity, i
On Fri, May 30, 2014 at 10:49:29AM +0800, Ming Lei wrote:
> Firstly, it isn't necessary to hold lock of vblk->vq_lock
> when notifying hypervisor about queued I/O.
>
> Secondly, virtqueue_notify() will cause world switch and
> it may take long time on some hypervisors(such as, qemu-arm),
> so it i
On 2014-05-30 00:10, Rusty Russell wrote:
Jens Axboe writes:
If Rusty agrees, I'd like to add it for 3.16 with a stable marker.
Really stable? It improves performance, which is nice. But every patch
which goes into the kernel fixes a bug, improves clarity, improves
performance or adds a fea
Ming Lei writes:
> Firstly, it isn't necessary to hold lock of vblk->vq_lock
> when notifying hypervisor about queued I/O.
>
> Secondly, virtqueue_notify() will cause world switch and
> it may take long time on some hypervisors(such as, qemu-arm),
> so it isn't good to hold the lock and block othe
Jens Axboe writes:
> If Rusty agrees, I'd like to add it for 3.16 with a stable marker.
Really stable? It improves performance, which is nice. But every patch
which goes into the kernel fixes a bug, improves clarity, improves
performance or adds a feature. I've now seen all four cases get CC'd
On Fri, May 30, 2014 at 11:35 AM, Jens Axboe wrote:
> On 2014-05-29 21:34, Ming Lei wrote:
>>
>> On Fri, May 30, 2014 at 11:19 AM, Jens Axboe wrote:
>>>
>>> On 2014-05-29 20:49, Ming Lei wrote:
Firstly, it isn't necessary to hold lock of vblk->vq_lock
when notifying hypervisor
On Fri, May 30, 2014 at 11:19 AM, Jens Axboe wrote:
> On 2014-05-29 20:49, Ming Lei wrote:
>>
>> Firstly, it isn't necessary to hold lock of vblk->vq_lock
>> when notifying hypervisor about queued I/O.
>>
>> Secondly, virtqueue_notify() will cause world switch and
>> it may take long time on some
On 2014-05-29 21:34, Ming Lei wrote:
On Fri, May 30, 2014 at 11:19 AM, Jens Axboe wrote:
On 2014-05-29 20:49, Ming Lei wrote:
Firstly, it isn't necessary to hold lock of vblk->vq_lock
when notifying hypervisor about queued I/O.
Secondly, virtqueue_notify() will cause world switch and
it may
On 2014-05-29 20:49, Ming Lei wrote:
Firstly, it isn't necessary to hold lock of vblk->vq_lock
when notifying hypervisor about queued I/O.
Secondly, virtqueue_notify() will cause world switch and
it may take long time on some hypervisors(such as, qemu-arm),
so it isn't good to hold the lock and
Firstly, it isn't necessary to hold lock of vblk->vq_lock
when notifying hypervisor about queued I/O.
Secondly, virtqueue_notify() will cause world switch and
it may take long time on some hypervisors(such as, qemu-arm),
so it isn't good to hold the lock and block other vCPUs.
On arm64 quad core
13 matches
Mail list logo
