linux-kernel - Re: [PATCH 00/13] KVM: MMU: fast page fault

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F842074.1050108@linux.vnet.ibm.com>
Date:	Tue, 10 Apr 2012 19:58:44 +0800
From:	Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>
To:	Takuya Yoshikawa <takuya.yoshikawa@...il.com>
CC:	Avi Kivity <avi@...hat.com>, Marcelo Tosatti <mtosatti@...hat.com>,
	Xiao Guangrong <xiaoguangrong.eric@...il.com>,
	LKML <linux-kernel@...r.kernel.org>, KVM <kvm@...r.kernel.org>
Subject: Re: [PATCH 00/13] KVM: MMU: fast page fault

On 04/10/2012 07:40 PM, Takuya Yoshikawa wrote:

> On Tue, 10 Apr 2012 13:39:14 +0300
> Avi Kivity <avi@...hat.com> wrote:
> 
>> On 04/09/2012 10:46 PM, Marcelo Tosatti wrote:
>>> Perhaps the mmu_lock hold times by get_dirty are a large component here?
>>> If that can be alleviated, not only RO->RW faults benefit.
>>>
>>>
>>
>> Currently the longest holder in normal use is probably reading the dirty
>> log and write protecting the shadow page tables.
>>
>> We could fix that by switching to O(1) write protection
>> (write-protecting PML4Es instead of PTEs).  It would be interesting to
>> combine O(1) write protection with lockless write-enabling.
>>
> 
> As Marcelo suggested during reviewing srcu-less dirty logging, we can
> mitigate the get_dirty's mmu_lock hold time problem cleanly, locally in
> get_dirty_log(), by using cond_resched_lock() -- although we need to
> introduce cond_rescheck_lock_cb() to conditionally flush TLB.
> 


Although it can reduce the contention but it is not reduce the overload
of dirty-log.


> I have already started that work.
> 
> Actually I introduced rmap based get_dirty for that kind of fine-grained
> contention control.
> 


I do not think this way is better that O(1). Avi has explained the reason
for many times, and i agree with that. :)

> I think we should do our best not to affect mmu so much just for the
> limited time of live migration.
> 


No, i do not really agree with that.

We really can get great benefit from O(1) especially if lockless write-protect
is introduced for O(1), live migration is very useful for cloud computing
architecture to balance the overload on all nodes.

And no reason to disallow us touch the code of MMU, yes, it needs simply
but it does not means stop the development of MMU.

For another hander, the mechanism like your to improve dirty-log also need
introduce lots of code and it does not make MMU clearer. :)

--
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/