From: Oleg Nesterov <[EMAIL PROTECTED]>
Pointed out by Michal Schmidt <[EMAIL PROTECTED]>.
The bug was introduced in 2.6.22 by me.
cleanup_workqueue_thread() does flush_cpu_workqueue(cwq) in a loop until
->worklist becomes empty. This is live-lockable, a re-niced caller can get
CPU after wake_
Oleg Nesterov wrote:
> Pointed out by Michal Schmidt <[EMAIL PROTECTED]>.
>
> The bug was introduced in 2.6.22 by me.
>
> cleanup_workqueue_thread() does flush_cpu_workqueue(cwq) in a loop until
> ->worklist becomes empty. This is live-lockable, a re-niced caller can
> get CPU after wake_up() and
Pointed out by Michal Schmidt <[EMAIL PROTECTED]>.
The bug was introduced in 2.6.22 by me.
cleanup_workqueue_thread() does flush_cpu_workqueue(cwq) in a loop until
->worklist becomes empty. This is live-lockable, a re-niced caller can
get CPU after wake_up() and insert a new barrier before the lo
Michal Schmidt wrote:
>
> While using SystemTap I noticed an interesting situation. When my stap
> probe was exiting, there was a several seconds long delay, during which
> the CPU was 100% loaded. I narrowed the problem down to destroy_workqueue.
>
> The attached module is a minimized testcase. To
Hi,
While using SystemTap I noticed an interesting situation. When my stap
probe was exiting, there was a several seconds long delay, during which
the CPU was 100% loaded. I narrowed the problem down to destroy_workqueue.
The attached module is a minimized testcase. To reproduce it, load the
modu
5 matches
Mail list logo