New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Do you care CPU instruction sets?
OstCollector
Member
I made a test on kvm boxes from @miTgiB , @Francisco and @prometeus about openssl, and found aes-ni is enabled only on @Francisco.
@Francisco has E3-1230, @prometeus has E5-2620. Not sure but believe @miTgiB has moved to E3/E5s as 'DPPS' doesn't trigger a SIGILL.
Also, @Francisco support "march=corei7-avx" compile flag, and the rest fails to use this.
Personally, I hope to use newer CPU features, how do you deal / think of this?
PS: I am a gentoo user, compiling from local mirror.
Comments
I pass a different flag set in our libvirt files than the rest.
I've not confirmed if AES-NI actually works inside a KVM, though.
Francisco
It's important. For OpenSSL I've found Ivy Bridge (E3 v2) having a better instructions than Sandy Bridge (E3).
Don't quote me but it's not aes-ni. Been a while since I played with nginx and OpenSSL.
Correct me if I am wrong, but I was always under the impression that Sandy and Ivy are the same instruction set, just one has a smaller fabrication process, slightly faster and uses less power.
I thought it was the same? AES-NI is what helps openssl, if you compile for it.
You get like a 10x boost in performance.
Francisco
Be aware that all nodes need the same cpu instruction sets for a migration. If you have older and new cpus in use it must be the smallerst cpu instruction sets. With cpu=host should possible to work with the aes-ni instructions inside the vm.
They sometimes add a few things.
There's an extra function/instruction openssl picks up for the openssl hardware acceleration.
Here is the result from a buyvm storage box
with aes-ni (openssl speed -evp aes-128-cbc aes-256-cbc)
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128 cbc 569156.35k 623129.43k 637170.86k 641118.89k 644206.28k
aes-256 cbc 66778.53k 68780.41k 68643.75k 175028.31k 176174.42k
without (openssl speed aes-128-cbc aes-256-cbc)
aes-128 cbc 87262.10k 94820.37k 97292.71k 225481.38k 236124.13k
aes-256 cbc 63926.48k 68285.27k 68295.08k 167436.33k 168173.57k
I don't know why aes-256 cbc don't boost, but aes-128 cbc has a great boost.
The cpu seems to be Sandy Bridge E3-1230
model name : Intel(R) Xeon(R) CPU E31230 @ 3.20GHz
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc up arch_perfmon rep_good nopl pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt aes xsave avx hypervisor lahf_lm xsaveopt
Having AES-NI helps Tor performance to a ridiculous degree, easily slashing its CPU usage by 5-10x.
Did you ask Tim to enable passthrough?
He is maybe waiting for the next version of SolusVM. I remember I submitted a ticket in late Feb.
And I don't know how @prometeus will deal with it.
I'm current waiting for a small while.
Another SolusVM feature that doesn't really work, or the version of libvirt, but when adding in a custom config cpu=host it never passes through
It works on Solus, but you have to do it with a 'custom config', and it's EXTREMELY touchy. Usually takes me 3-5 tries to get any config changes to stick.