On Sun, Feb 24, 2019 at 11:45:35AM -0800, Andy Lutomirski wrote: > On Thu, Feb 21, 2019 at 2:57 PM Yu, Fenghua <fenghua...@intel.com> wrote: > > > > > From: Fenghua Yu [mailto:fenghua...@intel.com] > > > On Wed, Feb 20, 2019 at 10:37:27PM -0800, Andy Lutomirski wrote: > > > Or to simplify the situation, how about we still use zero as global max > > > wait > > > time (i.e. no limitation for global wait time) as implemented in this > > > patch > > > set? User can still change the value to any value based on their usage. > > > Isn't > > > this a right way to take care of any usage? > > > > Plus, if scheduler timers works, umwait will be forced time out by timer in > > HZ anyway. > > Indeed. But, on some configs, the scheduler timer intentionally will > *not* fire. > > > > > Only for case without scheduler timer, sysadmin may need to set a small max > > umwait time to force timout. But in this case (real time), I doubt user app > > really wants to call umwait to save power with long latency of waking up > > from umwait. So likely in this case, user app won't call umwait and there > > is no usage to set a small value for max umwait time. > > I don't really know why an application would use umwait at all. About > the only legitimate use I can think of is to treat it as a somewhat > power-saving variant of REP NOP. What I want to avoid is the case > where it works dramatically differently on NO_HZ_FULL systems as > compared to everything else. Also, UMWAIT may behave a bit > differently if the max timeout is hit, and I'd like that path to get > exercised widely by making it happen even on default configs. > > 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.
OK. I will set the default umwait max time value to 100K cycles. Thanks. -Fenghua
