1. 28 11月, 2012 1 次提交
  2. 15 11月, 2012 1 次提交
    • Y
      cpuidle: Quickly notice prediction failure for repeat mode · 69a37bea
      Youquan Song 提交于
      The prediction for future is difficult and when the cpuidle governor prediction
      fails and govenor possibly choose the shallower C-state than it should. How to
      quickly notice and find the failure becomes important for power saving.
      
      cpuidle menu governor has a method to predict the repeat pattern if there are 8
      C-states residency which are continuous and the same or very close, so it will
      predict the next C-states residency will keep same residency time.
      
      There is a real case that turbostat utility (tools/power/x86/turbostat)
      at kernel 3.3 or early. turbostat utility will read 10 registers one by one at
      Sandybridge, so it will generate 10 IPIs to wake up idle CPUs. So cpuidle menu
       governor will predict it is repeat mode and there is another IPI wake up idle
       CPU soon, so it keeps idle CPU stay at C1 state even though CPU is totally
      idle. However, in the turbostat, following 10 registers reading is sleep 5
      seconds by default, so the idle CPU will keep at C1 for a long time though it is
       idle until break event occurs.
      In a idle Sandybridge system, run "./turbostat -v", we will notice that deep
      C-state dangles between "70% ~ 99%". After patched the kernel, we will notice
      deep C-state stays at >99.98%.
      
      In the patch, a timer is added when menu governor detects a repeat mode and
      choose a shallow C-state. The timer is set to a time out value that greater
      than predicted time, and we conclude repeat mode prediction failure if timer is
      triggered. When repeat mode happens as expected, the timer is not triggered
      and CPU waken up from C-states and it will cancel the timer initiatively.
      When repeat mode does not happen, the timer will be time out and menu governor
      will quickly notice that the repeat mode prediction fails and then re-evaluates
      deeper C-states possibility.
      
      Below is another case which will clearly show the patch much benefit:
      
      #include <stdlib.h>
      #include <stdio.h>
      #include <unistd.h>
      #include <signal.h>
      #include <sys/time.h>
      #include <time.h>
      #include <pthread.h>
      
      volatile int * shutdown;
      volatile long * count;
      int delay = 20;
      int loop = 8;
      
      void usage(void)
      {
      	fprintf(stderr,
      		"Usage: idle_predict [options]\n"
      		"  --help	-h  Print this help\n"
      		"  --thread	-n  Thread number\n"
      		"  --loop     	-l  Loop times in shallow Cstate\n"
      		"  --delay	-t  Sleep time (uS)in shallow Cstate\n");
      }
      
      void *simple_loop() {
      	int idle_num = 1;
      	while (!(*shutdown)) {
      		*count = *count + 1;
      
      		if (idle_num % loop)
      			usleep(delay);
      		else {
      			/* sleep 1 second */
      			usleep(1000000);
      			idle_num = 0;
      		}
      		idle_num++;
      	}
      
      }
      
      static void sighand(int sig)
      {
      	*shutdown = 1;
      }
      
      int main(int argc, char *argv[])
      {
      	sigset_t sigset;
      	int signum = SIGALRM;
      	int i, c, er = 0, thread_num = 8;
      	pthread_t pt[1024];
      
      	static char optstr[] = "n:l:t:h:";
      
      	while ((c = getopt(argc, argv, optstr)) != EOF)
      		switch (c) {
      			case 'n':
      				thread_num = atoi(optarg);
      				break;
      			case 'l':
      				loop = atoi(optarg);
      				break;
      			case 't':
      				delay = atoi(optarg);
      				break;
      			case 'h':
      			default:
      				usage();
      				exit(1);
      		}
      
      	printf("thread=%d,loop=%d,delay=%d\n",thread_num,loop,delay);
      	count = malloc(sizeof(long));
      	shutdown = malloc(sizeof(int));
      	*count = 0;
      	*shutdown = 0;
      
      	sigemptyset(&sigset);
      	sigaddset(&sigset, signum);
      	sigprocmask (SIG_BLOCK, &sigset, NULL);
      	signal(SIGINT, sighand);
      	signal(SIGTERM, sighand);
      
      	for(i = 0; i < thread_num ; i++)
      		pthread_create(&pt[i], NULL, simple_loop, NULL);
      
      	for (i = 0; i < thread_num; i++)
      		pthread_join(pt[i], NULL);
      
      	exit(0);
      }
      
      Get powertop V2 from git://github.com/fenrus75/powertop, build powertop.
      After build the above test application, then run it.
      Test plaform can be Intel Sandybridge or other recent platforms.
      #./idle_predict -l 10 &
      #./powertop
      
      We will find that deep C-state will dangle between 40%~100% and much time spent
      on C1 state. It is because menu governor wrongly predict that repeat mode
      is kept, so it will choose the C1 shallow C-state even though it has chance to
      sleep 1 second in deep C-state.
      
      While after patched the kernel, we find that deep C-state will keep >99.6%.
      Signed-off-by: NRik van Riel <riel@redhat.com>
      Signed-off-by: NYouquan Song <youquan.song@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      69a37bea
  3. 14 11月, 2012 2 次提交
  4. 01 11月, 2012 2 次提交
  5. 24 10月, 2012 1 次提交
  6. 16 10月, 2012 3 次提交
  7. 10 10月, 2012 1 次提交
  8. 05 10月, 2012 1 次提交
    • F
      nohz: Fix one jiffy count too far in idle cputime · 2b17c545
      Frederic Weisbecker 提交于
      When we stop the tick in idle, we save the current jiffies value
      in ts->idle_jiffies. This snapshot is substracted from the later
      value of jiffies when the tick is restarted and the resulting
      delta is accounted as idle cputime. This is how we handle the
      idle cputime accounting without the tick.
      
      But sometimes we need to schedule the next tick to some time in
      the future instead of completely stopping it. In this case, a
      tick may happen before we restart the periodic behaviour and
      from that tick we account one jiffy to idle cputime as usual but
      we also increment the ts->idle_jiffies snapshot by one so that
      when we compute the delta to account, we substract the one jiffy
      we just accounted.
      
      To prepare for stopping the tick outside idle, we introduced a
      check that prevents from fixing up that ts->idle_jiffies if we
      are not running the idle task. But we use idle_cpu() for that
      and this is a problem if we run the tick while another CPU
      remotely enqueues a ttwu to our runqueue:
      
      CPU 0:                            CPU 1:
      
      tick_sched_timer() {              ttwu_queue_remote()
             if (idle_cpu(CPU 0))
                 ts->idle_jiffies++;
      }
      
      Here, idle_cpu() notes that &rq->wake_list is not empty and
      hence won't consider the CPU as idle. As a result,
      ts->idle_jiffies won't be incremented. But this is wrong because
      we actually account the current jiffy to idle cputime. And that
      jiffy won't get substracted from the nohz time delta. So in the
      end, this jiffy is accounted twice.
      
      Fix this by changing idle_cpu(smp_processor_id()) with
      is_idle_task(current). This way the jiffy is substracted
      correctly even if a ttwu operation is enqueued on the CPU.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: <stable@vger.kernel.org> # 3.5+
      Link: http://lkml.kernel.org/r/1349308004-3482-1-git-send-email-fweisbec@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      2b17c545
  9. 25 9月, 2012 8 次提交
    • J
      time: Only do nanosecond rounding on GENERIC_TIME_VSYSCALL_OLD systems · 92bb1fcf
      John Stultz 提交于
      We only do rounding to the next nanosecond so we don't see minor
      1ns inconsistencies in the vsyscall implementations. Since we're
      changing the vsyscall implementations to avoid this, conditionalize
      the rounding only to the GENERIC_TIME_VSYSCALL_OLD architectures.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Turner <pjt@google.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      92bb1fcf
    • J
      time: Introduce new GENERIC_TIME_VSYSCALL · 576094b7
      John Stultz 提交于
      Now that we moved everyone over to GENERIC_TIME_VSYSCALL_OLD,
      introduce the new declaration and config option for the new
      update_vsyscall method.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Turner <pjt@google.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      576094b7
    • J
      time: Convert CONFIG_GENERIC_TIME_VSYSCALL to CONFIG_GENERIC_TIME_VSYSCALL_OLD · 70639421
      John Stultz 提交于
      To help migrate archtectures over to the new update_vsyscall method,
      redfine CONFIG_GENERIC_TIME_VSYSCALL as CONFIG_GENERIC_TIME_VSYSCALL_OLD
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Turner <pjt@google.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      70639421
    • J
      time: Move timekeeper structure to timekeeper_internal.h for vsyscall changes · d7b4202e
      John Stultz 提交于
      We're going to need to access the timekeeper in update_vsyscall,
      so make the structure available for those who need it.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Turner <pjt@google.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      d7b4202e
    • J
      jiffies: Remove compile time assumptions about CLOCK_TICK_RATE · b3c869d3
      John Stultz 提交于
      CLOCK_TICK_RATE is used to accurately caclulate exactly how
      a tick will be at a given HZ.
      
      This is useful, because while we'd expect NSEC_PER_SEC/HZ,
      the underlying hardware will have some granularity limit,
      so we won't be able to have exactly HZ ticks per second.
      
      This slight error can cause timekeeping quality problems
      when using the jiffies or other jiffies driven clocksources.
      Thus we currently use compile time CLOCK_TICK_RATE value to
      generate SHIFTED_HZ and NSEC_PER_JIFFIES, which we then use
      to adjust the jiffies clocksource to correct this error.
      
      Unfortunately though, since CLOCK_TICK_RATE is a compile
      time value, and the jiffies clocksource is registered very
      early during boot, there are a number of cases where there
      are different possible hardware timers that have different
      tick rates. This causes problems in cases like ARM where
      there are numerous different types of hardware, each having
      their own compile-time CLOCK_TICK_RATE, making it hard to
      accurately support different hardware with a single kernel.
      
      For the most part, this doesn't matter all that much, as not
      too many systems actually utilize the jiffies or jiffies driven
      clocksource. Usually there are other highres clocksources
      who's granularity error is negligable.
      
      Even so, we have some complicated calcualtions that we do
      everywhere to handle these edge cases.
      
      This patch removes the compile time SHIFTED_HZ value, and
      introduces a register_refined_jiffies() function. This results
      in the default jiffies clock as being assumed a perfect HZ
      freq, and allows archtectures that care about jiffies accuracy
      to call register_refined_jiffies() with the tick rate, specified
      dynamically at boot.
      
      This allows us, where necessary, to not have a compile time
      CLOCK_TICK_RATE constant, simplifies the jiffies code, and
      still provides a way to have an accurate jiffies clock.
      
      NOTE: Since this patch does not add register_refinied_jiffies()
      calls for every arch, it may cause time quality regressions
      in some cases. Its likely these will not be noticable, but
      if they are an issue, adding the following to the end of
      setup_arch() should resolve the regression:
      	register_refinied_jiffies(CLOCK_TICK_RATE)
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      b3c869d3
    • J
      alarmtimer: Rename alarmtimer_remove to alarmtimer_dequeue · a65bcc12
      John Stultz 提交于
      Now that alarmtimer_remove has been simplified, change
      its name to _dequeue to better match its paired _enqueue
      function.
      
      Cc: Arve Hjønnevåg <arve@android.com>
      Cc: Colin Cross <ccross@android.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      a65bcc12
    • J
      alarmtimer: Use hrtimer per-alarm instead of per-base · dae373be
      John Stultz 提交于
      Arve Hjønnevåg reported numerous crashes from the
      "BUG_ON(timer->state != HRTIMER_STATE_CALLBACK)" check
      in __run_hrtimer after it called alarmtimer_fired.
      
      It ends up the alarmtimer code was not properly handling
      possible failures of hrtimer_try_to_cancel, and because
      these faulres occur when the underlying base hrtimer is
      being run, this limits the ability to properly handle
      modifications to any alarmtimers on that base.
      
      Because much of the logic duplicates the hrtimer logic,
      it seems that we might as well have a per-alarmtimer
      hrtimer, and avoid the extra complextity of trying to
      multiplex many alarmtimers off of one hrtimer.
      
      Thus this patch moves the hrtimer to the alarm structure
      and simplifies the management logic.
      
      Changelog:
      v2:
      * Includes a fix for double alarm_start calls found by
        Arve
      
      Cc: Arve Hjønnevåg <arve@android.com>
      Cc: Colin Cross <ccross@android.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Reported-by: NArve Hjønnevåg <arve@android.com>
      Tested-by: NArve Hjønnevåg <arve@android.com>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      dae373be
    • T
      alarmtimer: Implement minimum alarm interval for allowing suspend · 59a93c27
      Todd Poynor 提交于
      alarmtimer suspend return -EBUSY if the next alarm will fire in less
      than 2 seconds.  This allows one RTC seconds tick to occur subsequent
      to this check before the alarm wakeup time is set, ensuring the wakeup
      time is still in the future (assuming the RTC does not tick one more
      second prior to setting the alarm).
      
      If suspend is rejected due to an imminent alarm, hold a wakeup source
      for 2 seconds to process the alarm prior to reattempting suspend.
      
      If setting the alarm incurs an -ETIME for an alarm set in the past,
      or any other problem setting the alarm, abort suspend and hold a
      wakelock for 1 second while the alarm is allowed to be serviced or
      other hopefully transient conditions preventing the alarm clear up.
      Signed-off-by: NTodd Poynor <toddpoynor@google.com>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      59a93c27
  10. 23 9月, 2012 1 次提交
    • P
      time: RCU permitted to stop idle entry via softirq · 803b0eba
      Paul E. McKenney 提交于
      The can_stop_idle_tick() function complains if a softirq vector is
      raised too late in the idle-entry process, presumably in order to
      prevent dangling softirq invocations from being delayed across the
      full idle period, which might be indefinitely long -- and if softirq
      was asserted any later than the call to this function, such a delay
      might well happen.
      
      However, RCU needs to be able to use softirq to stop idle entry in
      order to be able to drain RCU callbacks from the current CPU, which in
      turn enables faster entry into dyntick-idle mode, which in turn reduces
      power consumption.  Because RCU takes this action at a well-defined
      point in the idle-entry path, it is safe for RCU to take this approach.
      
      This commit therefore silences the error message that is sometimes
      produced when the going-idle CPU suddenly finds that it has an RCU_SOFTIRQ
      to process.  The error message will continue to be issued for other
      softirq vectors.
      Reported-by: NSedat Dilek <sedat.dilek@gmail.com>
      Signed-off-by: NPaul E. McKenney <paul.mckenney@linaro.org>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
      Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
      803b0eba
  11. 13 9月, 2012 2 次提交
  12. 04 9月, 2012 2 次提交
  13. 02 9月, 2012 1 次提交
    • J
      time: Move ktime_t overflow checking into timespec_valid_strict · cee58483
      John Stultz 提交于
      Andreas Bombe reported that the added ktime_t overflow checking added to
      timespec_valid in commit 4e8b1452 ("time: Improve sanity checking of
      timekeeping inputs") was causing problems with X.org because it caused
      timeouts larger then KTIME_T to be invalid.
      
      Previously, these large timeouts would be clamped to KTIME_MAX and would
      never expire, which is valid.
      
      This patch splits the ktime_t overflow checking into a new
      timespec_valid_strict function, and converts the timekeeping codes
      internal checking to use this more strict function.
      Reported-and-tested-by: NAndreas Bombe <aeb@debian.org>
      Cc: Zhouping Liu <zliu@redhat.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cee58483
  14. 22 8月, 2012 4 次提交
  15. 15 8月, 2012 1 次提交
  16. 05 8月, 2012 1 次提交
    • I
      time: Fix adjustment cleanup bug in timekeeping_adjust() · 1d17d174
      Ingo Molnar 提交于
      Tetsuo Handa reported that sporadically the system clock starts
      counting up too quickly which is enough to confuse the hangcheck
      timer to print a bogus stall warning.
      
      Commit 2a8c0883 "time: Move xtime_nsec adjustment underflow handling
      timekeeping_adjust" overlooked this exit path:
      
              } else
                      return;
      
      which should really be a proper exit sequence, fixing the bug as a
      side effect.
      
      Also make the flow more readable by properly balancing curly
      braces.
      
      Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
      Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Cc: john.stultz@linaro.org
      Cc: a.p.zijlstra@chello.nl
      Cc: richardcochran@gmail.com
      Cc: prarit@redhat.com
      Link: http://lkml.kernel.org/r/20120804192114.GA28347@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      1d17d174
  17. 31 7月, 2012 4 次提交
  18. 24 7月, 2012 1 次提交
  19. 17 7月, 2012 1 次提交
  20. 15 7月, 2012 2 次提交