linux-kernel - Re: [PATCH v7 10/11] KVM: MMU: collapse TLB flushes when zap all pages

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: <51A6006D.5060601@linux.vnet.ibm.com>
Date:	Wed, 29 May 2013 21:19:41 +0800
From:	Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>
To:	Marcelo Tosatti <mtosatti@...hat.com>
CC:	gleb@...hat.com, avi.kivity@...il.com, pbonzini@...hat.com,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v7 10/11] KVM: MMU: collapse TLB flushes when zap all
 pages

On 05/29/2013 08:39 PM, Marcelo Tosatti wrote:
> On Wed, May 29, 2013 at 11:03:19AM +0800, Xiao Guangrong wrote:
>>>>> the pages since other vcpus may be doing locklessly shadow
>>>>> page walking
>>>
>>> Ah, yes, i agree with you.
>>>
>>> We can introduce a list, say kvm->arch.obsolte_pages, to link all of the
>>> zapped-page, the page-shrink will free the page on that list first.
>>>
>>> Marcelo, if you do not have objection on  patch 1 ~ 8 and 11, could you please
>>> let them merged first, and do add some comments and tlb optimization later?
>>
>> Exclude patch 11 please, since it depends on the "collapse" optimization.
> 
> I'm fine with patch 1 being merged. I think the remaining patches need better
> understanding or explanation. The problems i see are:
> 
> 1) The magic number "10" to zap before considering reschedule is
> annoying. It would be good to understand why it is needed at all.

......

> 
> But then again, the testcase is measuring kvm_mmu_zap_all performance
> alone which we know is not a common operation, so perhaps there is
> no need for that minimum-pages-to-zap-before-reschedule.

Well. Although, this is not the common operation, but this operation
can be triggered by VCPU - it one VCPU take long time on zap-all-pages,
other vcpus is missing IPI-synce, or missing IO. This is easily cause
soft lockups if the vcpu is doing memslot-releated things.

> 
> 2) The problem above (retention of large number of pages while zapping)
> can be fatal, it can lead to OOM and host crash.

This problem is introduced in this patch (patch 10), without this patch,
the pages are always be zapped before release the mmu-lock.

> 
> 3) Make sure that introduction of obsolete pages can not lead to a 
> huge number of shadow pages around (the correct reason you gave for not merging
> https://patchwork.kernel.org/patch/2309641/ is not true anymore
> obsolete pages).

Actually, this question is the same as 2). It also the page-reclaim problem.
Without patch #10, no problem.

> 
> Other than these points, i'm fine with obsolete pages optimization
> to speed up kvm_mmu_zap_all and the rest of the patchset.

Thank you!


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