Time Stamp Counter does not stop in C states
swapping the high & low bits of a long value during a MOV) instruction (currently only available on Intel Atom processors) LAHF/SAHF (Load/Store Flags into AH Register) instruction in Long ModeĪMD LBR (Last Branch Record) Virtualization supportĪMD's misaligned accesses for SSE instructions
Intel Haswell hardware lock elision (transactional memory support) Intel FS/GS Base registers access instructions, part of AVX Intel enhanced REP MOVSB/STOSB instructionsġ6-bit floating-point conversion instructionsĪMD flush-by-ASID (Address Space ID) supportĪMD 4-operand fused multiply-add instructions TPR: Task Priority Register) in 32-bit modeĭirect Cache Access (the ability to prefetch data from MMIO)ĬPL-qualified debug store (CPL=Current Privilege Level) Time Stamp Counter ticks at a constant rateĬR8 (Control Register #8, a.k.a. L1 Context ID: the L1 data cache can be set to adaptive or shared mode by the BIOSĬMOV (conditional move) instructions (plus FCMOVcc, FCOMI with FPU) The first group includes instructions such as ANDN, BEXTR, BLSI, BLSMK, BLSR, TZCNT, and the second group, BZHI, MULX, PDEP, PEXT, RORX, SARX, SHLX, SHRX.Ĭentaur MCRs (= MTRRs, Memory Type Range Registers) Intel 1st/2nd group advanced bit manipulation extensions. On-chip APIC (Advanced Programmable Interrupt Controller) XCRYPTxxx instructionsĪCPI (Advanced Configuration and Power Interface) via MSR (Model-Specific Register)ĪES (Advanced Encryption Standard) instructionsĪMD multi-node processor (DCM=Direct Connect Module)Īctual Performance Clock Counter (APERF) and Maximum Qualified Performance Clock Counter (MPERF) in MSRs Here is the answer (from Linux kernel sourceĪMD Advanced Bit Manipulation instruction, i.e. But migrations of customers between do not happen very often, and in fact all CPUs used today in a hosting environment should support AES, as that's been implemented in server (and even desktop) CPUs a very very long time ago.Ever wonder what these "flags" in x86 Linux's /proc/cpuinfo mean ? So there is no risk to jeopardize encryption strength or security of Tor or other apps which you try this on.Īlso even if it works now, it may stop working down the line if the host migrates your VPS to a node with older CPU, one which doesn't support AES. If the underlying CPU actually doesn't support AES, all programs trying to use it (including `openssl speed`) will crash outright, with an “Illegal instruction” error. So now it has headroom to ramp up further.Ī word of caution, firstly always test as shown above to verify that it works. Seems to work just fine, my CPU usage is half of what it was before, at similar bandwidth levels. (but this will get overwritten and removed by the next Tor version upgrade).
CPUINFO AES INSTRUCTIONS HOW TO
# OPENSSL_ia32cap="+0x200000200000000" openssl speed -elapsed -evp aes-128-gcmĪes-128-gcm 59047.07k 104467.39k 141712.21k 151093.93k 158321.32k 156827.65kĪlmost 4 times faster! For Tor this leads to higher bandwidth utilization and lower CPU usage (which will actually make your VPS host happier :)īut how to apply that to Tor? Well, for some initial testing I just chose to add the following line to /etc/init.d/tor (not using systemd here), right after ”#! /bin/bash”:Įxport OPENSSL_ia32cap="+0x200000200000000" # openssl speed -elapsed -evp aes-128-gcm Testing OpenSSL speed in the default configuration. Model name : QEMU Virtual CPU version 1.5.3įlags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl eagerfpu pni cx16 hypervisor lahf_lmĪddress sizes : 46 bits physical, 48 bits virtual Let's take one VPS box with the aforementioned problem.
0 kommentar(er)
