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]
Date:	Tue, 11 Dec 2007 15:27:14 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	dor.laor@...ranet.com, linux-kernel@...r.kernel.org,
	tglx@...utronix.de
Subject: Re: Performance overhead of get_cycles_sync


[headers rewritten because of gmane crosspost breakage]

> In the latest kernel (2.6.24-rc3) I noticed a drastic performance 
> decrease for KVM networking.

That should not have changed for quite some time.

Also it depends on the CPU of course.

> The reason is many vmexit (exit reason is cpuid instruction) caused by
> calls to gettimeofday that uses tsc sourceclock.
> read_tsc calls get_cycles_sync which might call cpuid in order to 
> serialize the cpu.
>
> Can you explain why the cpu needs to be serialized for every gettime call?

Otherwise RDTSC can be speculated around and happen outside the protection
of the seqlock and that can sometimes lead to non monotonic time reporting.

Anyways after a lot of discussions it turns out there are ways to archive
this without CPUID and there is a solution implemented for this in ff
tree which I will submit for .25. It's a little complicated though
and not a quick fix.

> Do we need to be that accurate? (It will also slightly improve physical 
> hosts).
> I believe you have a reason and the answer is yes. In that case can you 
> replace the serializing instruction
> with an instruction that does not trigger vmexit? Maybe use 'ltr' for 
> example?

ltr doesn't synchronize RDTSC.

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