On Thu, Feb 21, 2019 at 2:57 PM Yu, Fenghua <[email protected]> wrote: > > > From: Fenghua Yu [mailto:[email protected]] > > 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. --Andy
