On Tue, Jun 11, 2019 at 11:01:45AM +0200, Peter Zijlstra wrote: > On Fri, Jun 07, 2019 at 03:00:32PM -0700, Fenghua Yu wrote: > > Today, if an application needs to wait for a very short duration > > they have to have spinloops. Spinloops consume more power and continue > > to use execution resources that could hurt its thread siblings in a core > > with hyperthreads. New instructions umonitor, umwait and tpause allow > > a low power alternative waiting at the same time could improve the HT > > sibling perform while giving it any power headroom. These instructions > > can be used in both user space and kernel space. > > > > A new MSR IA32_UMWAIT_CONTROL allows kernel to set a time limit in > > TSC-quanta that prevents user applications from waiting for a long time. > > This allows applications to yield the CPU and the user application > > should consider using other alternatives to wait. > > I'm confused on the purpose of this control; what do we win by limiting > this time?
In previous patches, there is no time limit (max time is 0 which means no time limit). Andy Lutomirski proposed to set the time limit: https://lkml.org/lkml/2019/2/26/735 "So I propose setting the timeout to either 100 microseconds or 100k "cycles" by default. In the event someone determines that they save materially more power or gets materially better performance with a longer timeout, we can revisit the value." Does it make sense? > > > .../ABI/testing/sysfs-devices-system-cpu | 21 ++ > > arch/x86/include/asm/cpufeatures.h | 1 + > > arch/x86/include/asm/msr-index.h | 4 + > > arch/x86/power/Makefile | 1 + > > arch/x86/power/umwait.c | 182 ++++++++++++++++++ > > You seem to miss the arch/x86/lib/delay.c change to use this fancy new > stuff for udelay(). I'm thinking that's exactly what TPAUSE is good for. There may be other places to use the instructions. But I think this patch set just first enables basic functionalities. We can focus on how to use the instructions in the future. Thanks. -Fenghua
