Messages in this thread | | | Date | Thu, 30 Mar 2017 15:44:01 +0200 | From | Frederic Weisbecker <> | Subject | Re: [BUG nohz]: wrong user and system time accounting |
| |
On Thu, Mar 30, 2017 at 09:02:31AM -0400, Rik van Riel wrote: > On Thu, 2017-03-30 at 14:51 +0200, Frederic Weisbecker wrote: > > On Thu, Mar 30, 2017 at 06:27:31AM +0200, Mike Galbraith wrote: > > > On Wed, 2017-03-29 at 16:08 -0400, Rik van Riel wrote: > > > > > > > A random offset, or better yet a somewhat randomized > > > > tick length to make sure that simultaneous ticks are > > > > fairly rare and the vtime sampling does not end up > > > > "in phase" with the jiffies incrementing, could make > > > > the accounting work right again. > > > > > > That improves jitter, especially on big boxen. I have an 8 socket > > > box > > > that thinks it's an extra large PC, there, collision avoidance > > > matters > > > hugely. I couldn't reproduce bean counting woes, no idea if > > > collision > > > avoidance will help that. > > > > Out of curiosity, where is the main contention between ticks? I > > indeed > > know some locks that can be taken on special cases, such as posix cpu > > timers. > > > > Also, why does it raise power consumption issues? > > On a system without either nohz_full or nohz idle > mode, skewed ticks result in CPU cores waking up > at different times, and keeping an idle system > consuming power for more time than it would if all > the ticks happened simultaneously.
Ah fair point!
> > This is not a factor at all on systems that switch > off the tick while idle, since the CPU will be busy > anyway while the tick is enabled.
I see. Thanks!
| |