On 12/03/2011 06:37 AM, Takuya Yoshikawa wrote:
> Avi Kivity wrote:
> > That's true. But some applications do require low latency, and the
> > current code can impose a lot of time with the mmu spinlock held.
> >
> > The total amount of work actually increases slightly, from O(N) to O(N
> > log
Avi Kivity wrote:
> That's true. But some applications do require low latency, and the
> current code can impose a lot of time with the mmu spinlock held.
>
> The total amount of work actually increases slightly, from O(N) to O(N
> log N), but since the tree is so wide, the overhead is small.
>
On 11/30/2011 07:15 AM, Takuya Yoshikawa wrote:
> (2011/11/30 14:02), Takuya Yoshikawa wrote:
>
>> IIUC, even though O(1) is O(1) at the timing of GET DIRTY LOG, it
>> needs O(N) write
>> protections with respect to the total number of dirty pages:
>> distributed, but
>> actually each page fault, w
On 11/30/2011 09:03 AM, Xiao Guangrong wrote:
> On 11/29/2011 08:01 PM, Avi Kivity wrote:
>
> > On 11/29/2011 01:56 PM, Xiao Guangrong wrote:
> >> On 11/29/2011 07:20 PM, Avi Kivity wrote:
> >>
> >>
> >>> We used to have a bitmap in a shadow page with a bit set for every slot
> >>> pointed to by th
On 11/29/2011 10:03 PM, Avi Kivity wrote:
> On 11/29/2011 02:01 PM, Avi Kivity wrote:
>> On 11/29/2011 01:56 PM, Xiao Guangrong wrote:
>>> On 11/29/2011 07:20 PM, Avi Kivity wrote:
>>>
>>>
We used to have a bitmap in a shadow page with a bit set for every slot
pointed to by the page. If
On 11/29/2011 08:01 PM, Avi Kivity wrote:
> On 11/29/2011 01:56 PM, Xiao Guangrong wrote:
>> On 11/29/2011 07:20 PM, Avi Kivity wrote:
>>
>>
>>> We used to have a bitmap in a shadow page with a bit set for every slot
>>> pointed to by the page. If we extend this to non-leaf pages (so, when
>>> we
(2011/11/30 14:02), Takuya Yoshikawa wrote:
IIUC, even though O(1) is O(1) at the timing of GET DIRTY LOG, it needs O(N)
write
protections with respect to the total number of dirty pages: distributed, but
actually each page fault, which should be logged, does some write protection?
Sorry, was
CCing qemu devel, Juan,
(2011/11/29 23:03), Avi Kivity wrote:
On 11/29/2011 02:01 PM, Avi Kivity wrote:
On 11/29/2011 01:56 PM, Xiao Guangrong wrote:
On 11/29/2011 07:20 PM, Avi Kivity wrote:
We used to have a bitmap in a shadow page with a bit set for every slot
pointed to by the page. If
On 11/29/2011 02:01 PM, Avi Kivity wrote:
> On 11/29/2011 01:56 PM, Xiao Guangrong wrote:
> > On 11/29/2011 07:20 PM, Avi Kivity wrote:
> >
> >
> > > We used to have a bitmap in a shadow page with a bit set for every slot
> > > pointed to by the page. If we extend this to non-leaf pages (so, when
On 11/29/2011 01:56 PM, Xiao Guangrong wrote:
> On 11/29/2011 07:20 PM, Avi Kivity wrote:
>
>
> > We used to have a bitmap in a shadow page with a bit set for every slot
> > pointed to by the page. If we extend this to non-leaf pages (so, when
> > we set a bit, we propagate it through its parent_p
On 11/29/2011 07:20 PM, Avi Kivity wrote:
> We used to have a bitmap in a shadow page with a bit set for every slot
> pointed to by the page. If we extend this to non-leaf pages (so, when
> we set a bit, we propagate it through its parent_ptes list), then we do
> the following on write fault:
>
On 11/29/2011 12:35 PM, Takuya Yoshikawa wrote:
>>> I think it needs more thinking if only less page need be write
>>> protected.
>>>
>>> For example, framebuffer-based device used by Xwindow, only ~64M
>>> pages needs
>>> to be write protected, but in your way, guest will get write page
>>> fault
(2011/11/29 19:09), Xiao Guangrong wrote:
Sorry, CC list is lost. :(
On 11/29/2011 06:01 PM, Xiao Guangrong wrote:
Avi Kivity redhat.com> writes:
On 11/16/2011 06:28 AM, Takuya Yoshikawa wrote:
(2011/11/14 21:39), Avi Kivity wrote:
There was a patchset from Peter Zijlstra that converted
Sorry, CC list is lost. :(
On 11/29/2011 06:01 PM, Xiao Guangrong wrote:
> Avi Kivity redhat.com> writes:
>
>>
>> On 11/16/2011 06:28 AM, Takuya Yoshikawa wrote:
>>> (2011/11/14 21:39), Avi Kivity wrote:
There was a patchset from Peter Zijlstra that converted mmu notifiers to
be preem
Avi Kivity redhat.com> writes:
>
> On 11/16/2011 06:28 AM, Takuya Yoshikawa wrote:
> > (2011/11/14 21:39), Avi Kivity wrote:
> >> There was a patchset from Peter Zijlstra that converted mmu notifiers to
> >> be preemptible, with that, we can convert the mmu spinlock to a mutex,
> >> I'll see wha
On 11/14/2011 11:20 AM, Takuya Yoshikawa wrote:
> This is a revised version of my previous work. I hope that
> the patches are more self explanatory than before.
>
>
Thanks, applied.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line
On 11/16/2011 06:28 AM, Takuya Yoshikawa wrote:
> (2011/11/14 21:39), Avi Kivity wrote:
>> There was a patchset from Peter Zijlstra that converted mmu notifiers to
>> be preemptible, with that, we can convert the mmu spinlock to a mutex,
>> I'll see what happened to it.
>
> Interesting!
>
>> There
Adding qemu-devel to Cc.
(2011/11/14 21:39), Avi Kivity wrote:
On 11/14/2011 12:56 PM, Takuya Yoshikawa wrote:
(2011/11/14 19:25), Avi Kivity wrote:
On 11/14/2011 11:20 AM, Takuya Yoshikawa wrote:
This is a revised version of my previous work. I hope that
the patches are more self explanator
(2011/11/14 21:39), Avi Kivity wrote:
There was a patchset from Peter Zijlstra that converted mmu notifiers to
be preemptible, with that, we can convert the mmu spinlock to a mutex,
I'll see what happened to it.
Interesting!
There is a third method of doing write protection, and that is by
wr
On 11/14/2011 12:56 PM, Takuya Yoshikawa wrote:
> (2011/11/14 19:25), Avi Kivity wrote:
>> On 11/14/2011 11:20 AM, Takuya Yoshikawa wrote:
>>> This is a revised version of my previous work. I hope that
>>> the patches are more self explanatory than before.
>>>
>>
>> It looks good. I'll let Marcel
(2011/11/14 19:25), Avi Kivity wrote:
On 11/14/2011 11:20 AM, Takuya Yoshikawa wrote:
This is a revised version of my previous work. I hope that
the patches are more self explanatory than before.
It looks good. I'll let Marcelo (or anyone else?) review it as well
before applying.
Do you ha
On 11/14/2011 11:20 AM, Takuya Yoshikawa wrote:
> This is a revised version of my previous work. I hope that
> the patches are more self explanatory than before.
>
It looks good. I'll let Marcelo (or anyone else?) review it as well
before applying.
Do you have performance measurements?
--
err
This is a revised version of my previous work. I hope that
the patches are more self explanatory than before.
Thanks,
Takuya
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.o
23 matches
Mail list logo
