On Tue, 10 Apr 2007 03:05:56 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote:
> My main > worry with keventd is that we might get stuck behind an unrelated > process for an undefined length of time. I don't think it has ever been demonstrated that keventd latency is excessive, or a problem. I guess we could instrument it and fix stuff easily enough. The main problem with keventd has been flush_scheduled_work() deadlocks: the caller of flush_scheduled_work() wants to flush work item A, but holds some lock which is also needed by unrelated work item B. Most of the time, it works. But if item B happens to be queued the flush_scheduled_work() will deadlock. The fix is to flush-and-cancel just item A: if it's not running yet, cancel it. If it is running, wait until it has finished. Oleg's void cancel_work_sync(struct work_struct *work) is queued for 2.6.22 and should permit some kthread->keventd conversions which would previously been deadlocky. The thing to concentrate on here is the per-cpu threads, which is where the proliferation appears to be coming from. Conversions to schedule_work()+cancel_work_sync() and conversions to create_singlethread_workqueue(). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/