Messages in this thread | | | Date | Mon, 17 Jun 2019 16:19:03 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH v4 0/5] x86/umwait: Enable user wait instructions |
| |
On Tue, Jun 11, 2019 at 10:37:34AM -0700, Fenghua Yu wrote: > 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?
You quoted exactly the wrong part of that message; Andy's concern was with NOHZ_FULL. And I think we should preserve that concern in both the code and Changelog introducing this limit.
| |