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,
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,
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
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
On Mon, Jun 2, 2014 at 9:23 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Jens Axboe ax...@kernel.dk writes:
On 2014-05-30 00:10, Rusty Russell wrote:
Jens Axboe ax...@kernel.dk writes:
If Rusty agrees, I'd like to add it for 3.16 with a stable marker.
Really stable? It improves
On 2014-06-01 19:23, Rusty Russell wrote:
Jens Axboe ax...@kernel.dk writes:
On 2014-05-30 00:10, Rusty Russell wrote:
Jens Axboe ax...@kernel.dk 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
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,
Jens Axboe ax...@kernel.dk writes:
On 2014-05-30 00:10, Rusty Russell wrote:
Jens Axboe ax...@kernel.dk 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,
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
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
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
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
Jens Axboe ax...@kernel.dk 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
Ming Lei ming@canonical.com 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
On 2014-05-30 00:10, Rusty Russell wrote:
Jens Axboe ax...@kernel.dk 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
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 isn't
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
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
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
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
On Fri, May 30, 2014 at 11:19 AM, Jens Axboe ax...@kernel.dk 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
On 2014-05-29 21:34, Ming Lei wrote:
On Fri, May 30, 2014 at 11:19 AM, Jens Axboe ax...@kernel.dk 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
On Fri, May 30, 2014 at 11:35 AM, Jens Axboe ax...@kernel.dk wrote:
On 2014-05-29 21:34, Ming Lei wrote:
On Fri, May 30, 2014 at 11:19 AM, Jens Axboe ax...@kernel.dk wrote:
On 2014-05-29 20:49, Ming Lei wrote:
Firstly, it isn't necessary to hold lock of vblk-vq_lock
when notifying
26 matches
Mail list logo
