Skip to content
Snippets Groups Projects
  1. Jan 14, 2021
  2. Dec 15, 2020
  3. Dec 01, 2020
  4. Nov 24, 2020
  5. Nov 20, 2020
  6. Nov 18, 2020
  7. Nov 04, 2020
  8. Oct 06, 2020
    • Satya Durga Srinivasu Prabhala's avatar
      sched/walt: fix suspicious RCU usage warning · 461a275d
      Satya Durga Srinivasu Prabhala authored
      
      Below warning is observed during boot when lockdep is enabled:
      
      [    0.122198] =============================
      [    0.126373] WARNING: suspicious RCU usage
      [    0.130545] 5.4.57-qgki-debug-g003be53-dirty #2 Not tainted
      [    0.136352] -----------------------------
      [    0.140526] include/linux/cgroup.h:488 suspicious rcu_dereference_check() usage!
      [    0.148159]
      [    0.148159] other info that might help us debug this:
      [    0.148159]
      [    0.156454]
      [    0.156454] rcu_scheduler_active = 1, debug_locks = 1
      [    0.163210] no locks held by swapper/0/0.
      [    0.167381]
      [    0.167381] stack backtrace:
      [    0.171942] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.57-qgki-debug-g003be53-dirty #2
      [    0.180347] Hardware name: Qualcomm Technologies, Inc. LahainaP MTP (DT)
      [    0.187233] Call trace:
      [    0.189770]  dump_backtrace.cfi_jt+0x0/0x4
      [    0.193994]  show_stack+0x18/0x24
      [    0.197420]  dump_stack+0xe0/0x160
      [    0.200930]  lockdep_rcu_suspicious+0x138/0x154
      [    0.205591]  add_new_task_to_grp+0x8c/0x1ac
      [    0.209893]  wake_up_new_task+0x38/0x1f4
      [    0.213942]  _do_fork+0x264/0x37c
      [    0.217362]  kernel_thread+0x50/0x78
      [    0.221054]  rest_init+0x2c/0x1f0
      [    0.224479]  start_kernel+0x0/0x424
      [    0.228070]  start_kernel+0x3ac/0x424
      
      Fix it by adding RCU lock while dereferencing css for the task.
      
      Change-Id: I3ef72f7e8abc2d40b7d954d8c1a486aead785333
      Signed-off-by: default avatarSatya Durga Srinivasu Prabhala <satyap@codeaurora.org>
      461a275d
  9. Sep 23, 2020
  10. Sep 21, 2020
    • Pavankumar Kondeti's avatar
      sched/walt: Fix a potential accounting issue during window size change · fce69881
      Pavankumar Kondeti authored
      
      There is a potential accounting issue during window size change, if
      the roll over is delayed such that the current task's mark start went
      past the new window start with the updated window size.
      
      For example, system is running with window size = 20 msec. So it would be
      like
      
      20 | 40 | 60 | 80 | 100 | 120
      
      At t= 98, the window size is changed to 8 msec. We expect this to be
      handled at the next window roll over i.e t = 100
      
      For some reason 98 < t < 109, interrupts are blocked on a CPU on which
      roll over is supposed to happen.
      
      Now at t = 109, the window roll over happen in the IRQ work. First
      we roll over the window such that
      
      wallclock (wc) = 109,
      mark_start (ms) = 109,
      window_start (ws) = 100.
      
      New window size is set to 8 msec. At this point, we did not realize that
      the ms/wc is went past the next window i.e 100 + 8 = 108 msec.
      
      At t = 110, a task wakes up. We first call update_task_ravg() on the
      current, for which ms = 109. We detect the window roll over but fail
      to roll over the CPU busy time counters (prs/crs) since ms > ws.
      see update_cpu_busy_time() for new_window detection. Now the utra()
      is called for the waking task and its ms < ws and we roll over window for
      it. if it migrates to another CPU, we try to subtract this task prs from
      the CPU's prs which is not updated. This results in accounting issues.
      
      This problem can be fixed easily by detecting the delayed window roll over
      and deferring the window size update to next window roll over. Since this
      is a very rare event, we don't miss anything. Also this is more optimized
      compared to any changes in update_task_ravg() which is called many times
      compared to a window roll over with a window size update pending.
      
      Change-Id: Ia6e1750e632bf7594f0f83656986ad4393bfbe5a
      Signed-off-by: default avatarPavankumar Kondeti <pkondeti@codeaurora.org>
      fce69881
  11. Sep 15, 2020
    • Shaleen Agrawal's avatar
      sched/walt: introduce trace_sched_ravg_window_change · 649fdbe0
      Shaleen Agrawal authored
      
      Currently we use a printk_deferred to notify when the window size
      changes. However, this adds a complication while debugging because it
      requires looking at the dmesg output. Instead, we introduce a trace
      hook, as this can be easily enabled for collections, and can help
      further improve scheduler debugging tools.
      
      Change-Id: I6809589748eef606403940567bd8c66a774b93ea
      Signed-off-by: default avatarShaleen Agrawal <shalagra@codeaurora.org>
      649fdbe0
  12. Sep 02, 2020
  13. Aug 27, 2020
  14. Aug 14, 2020
  15. Jul 30, 2020
  16. Jul 29, 2020
  17. Jul 28, 2020
  18. Jul 22, 2020
  19. Jul 21, 2020
  20. Jul 17, 2020
  21. Jun 30, 2020
  22. Jun 18, 2020
  23. Jun 14, 2020
  24. Jun 11, 2020
  25. Jun 08, 2020
  26. May 26, 2020
  27. May 16, 2020
  28. Apr 29, 2020
  29. Apr 13, 2020
  30. Mar 25, 2020
  31. Mar 20, 2020
  32. Feb 26, 2020
  33. Feb 11, 2020
  34. Jan 31, 2020
  35. Jan 28, 2020
Loading