[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F293D14.5030008@redhat.com>
Date: Wed, 01 Feb 2012 15:24:36 +0200
From: Avi Kivity <avi@...hat.com>
To: Takuya Yoshikawa <yoshikawa.takuya@....ntt.co.jp>
CC: Peter Zijlstra <peterz@...radead.org>, paulmck@...ux.vnet.ibm.com,
Oleg Nesterov <oleg@...hat.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Marcelo Tosatti <mtosatti@...hat.com>,
KVM list <kvm@...r.kernel.org>
Subject: Re: [RFC][PATCH] srcu: Implement call_srcu()
On 02/01/2012 01:12 PM, Takuya Yoshikawa wrote:
> (2012/02/01 20:01), Avi Kivity wrote:
>> On 02/01/2012 01:00 PM, Takuya Yoshikawa wrote:
>
>>> How about just doing:
>>>
>>> take a spin_lock
>>> copy the entire (or some portions of) bitmap locally
>>> clear the bitmap
>>> unlock
>>>
>>
>> That means that vcpus dirtying memory also have to take that lock, and
>> spin while the bitmap is being copied. So kvm_vm_ioctl_get_dirty_log()
>> will become faster, at the expense of vcpus, which I think is a bad
>> tradeoff.
>
> Almost every caller is already holding the mmu_lock.
True. But let's not add more locks.
>
> Isn't it possible to make others hold the lock only for the case of
> marking to the bitmap? (I will check myself too.)
Yes, in walk_addr(), while setting accessed and dirty bits in guest
PTEs, or while emulating instructions and writing to guest memory.
>> That'll be great, numbers are better than speculation.
>>
>
>
> Yes, I already have some good numbers to show (and some patches).
Looking forward.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists