On Thursday, March 22, 2018 6:19:16 PM CET Rik van Riel wrote: > On Thu, 2018-03-22 at 18:09 +0100, Rafael J. Wysocki wrote: > > On Thursday, March 22, 2018 5:32:23 PM CET Rik van Riel wrote: > > > On Wed, 2018-03-14 at 15:08 +0100, Rafael J. Wysocki wrote: > > > > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com> > > > > > > > > If poll_idle() is allowed to spin until need_resched() returns > > > > 'true', > > > > it may actually spin for a much longer time than expected by the > > > > idle > > > > governor, since set_tsk_need_resched() is not always called by > > > > the > > > > timer interrupt handler. If that happens, the CPU may spend much > > > > more time than anticipated in the "polling" state. > > > > > > > > To prevent that from happening, limit the time of the spinning > > > > loop > > > > in poll_idle(). > > > > > > > > Suggested-by: Peter Zijlstra <pet...@infradead.org> > > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com> > > > > > > So ... about bisecting that other patch series... > > > > > > It turned out I had this patch, which looks so > > > obviously correct, as patch #1 in my series. > > > > > > It also turned out that this patch is responsible > > > for the entire 5-10% increase in CPU use for the > > > memcache style workload. > > > > > > I wonder if keeping an idle HT thread much busier > > > than before slows down its sibling, or something > > > like that. > > > > Uhm, sorry about this. > > No worries, this is why we do patch reviews and > tests in the first place. > > > Does it improve if you do something like the below on top of it? > > That was my next thing to try, after testing just > the idle nohz series by itself :) > > I'll push both into the test systems, and will > get back to you when I have answers.
Thanks!
