Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 16 12月, 2010 3 次提交
  3. 15 12月, 2010 34 次提交
  5. 14 12月, 2010 3 次提交
    • S
      workqueue: It is likely that WORKER_NOT_RUNNING is true · 2d64672e
      由 Steven Rostedt 提交于 
      Running the annotate branch profiler on three boxes, including my
main box that runs firefox, evolution, xchat, and is part of the distcc farm,
showed this with the likelys in the workqueue code:

 correct incorrect  %        Function                  File              Line
 ------- ---------  -        --------                  ----              ----
      96   996253  99 wq_worker_sleeping             workqueue.c          703
      96   996247  99 wq_worker_waking_up            workqueue.c          677

The likely()s in this case were assuming that WORKER_NOT_RUNNING will
most likely be false. But this is not the case. The reason is
(and shown by adding trace_printks and testing it) that most of the time
WORKER_PREP is set.

In worker_thread() we have:

	worker_clr_flags(worker, WORKER_PREP);

	[ do work stuff ]

	worker_set_flags(worker, WORKER_PREP, false);

(that 'false' means not to wake up an idle worker)

The wq_worker_sleeping() is called from schedule when a worker thread
is putting itself to sleep. Which happens most of the time outside
of that [ do work stuff ].

The wq_worker_waking_up is called by the wakeup worker code, which
is also callod outside that [ do work stuff ].

Thus, the likely and unlikely used by those two functions are actually
backwards.

Remove the annotation and let gcc figure it out.
Acked-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NTejun Heo <tj@kernel.org>
      2d64672e
    • T
      MAINTAINERS: Add workqueue entry · 3e6cd7a4
      由 Tejun Heo 提交于 
      Signed-off-by: NTejun Heo <tj@kernel.org>
      3e6cd7a4
    • A
      fbdev: Fix fb_find_nearest_mode refresh comparison · e504b848
      由 Andrew Kephart 提交于 
      Refresh rate nearness is not calculated or reset when nearest resolution
changes.

This patch resets the refresh rate differential measurement whenever a
new nearest resolution is discovered.  This fixes two error cases;
first, wherein the first mode's refresh rate differential is never
calculated and second, when the closest refresh rate from a previous
nearest resolution is erroneously preserved.
Signed-off-by: NAndrew Kephart <andrew.kephart@alereon.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      e504b848