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: <5615F9AD.101@suse.com>
Date:	Thu, 8 Oct 2015 07:05:49 +0200
From:	Juergen Gross <jgross@...e.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	boris.ostrovsky@...cle.com, joao.m.martins@...cle.com,
	david.vrabel@...rix.com, dario.faggioli@...rix.com,
	xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] Use vAPIC when doing IPI for PVHVM guests.

On 10/07/2015 10:21 PM, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> I was running some tools in which we would heavily do rescheduling
> of events - and realized to my surprise that the event channels (and
> the hypercall) would slow things down. If I used the vAPIC with its
> IPI support (so no VMEXIT) I got much much better performance.
>
> Now this is an RFC because:
>   1). I hadn't verified from the xentrace  how much less VMEXITS we get.
>      But I remember Boris's patches and they gave at least 10%.
>      I think this will get the same performance or even better.
>
>   2). I don't know what to do with migration. That is if the guest
>      migrates to older hardware it needs to recheck this I presume?

Same problem applies to many other features. In case you want to
migrate to a machine with less features you'd have to mask those
features in the cpuid data of the domain.

>   3). Should this be enabled by default? I did get better performance
>     but that was synthetic.

Having some benchmark results would help to decide this. :-)

I'd be especially interested in checking "no vcpu over-commitment"
and "heavy vcpu over-commitment" scenarios regarding the effect of
the feature.

>
> Thoughts?

I like the idea.


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

Powered by Openwall GNU/*/Linux Powered by OpenVZ