Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752242AbaF1GVW (ORCPT ); Sat, 28 Jun 2014 02:21:22 -0400 Received: from mail-ie0-f175.google.com ([209.85.223.175]:37658 "EHLO mail-ie0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751339AbaF1GVU (ORCPT ); Sat, 28 Jun 2014 02:21:20 -0400 MIME-Version: 1.0 In-Reply-To: <1403926333.5113.12.camel@marge.simpson.net> References: <1403873856.5827.56.camel@marge.simpson.net> <20140627100157.6b0143a5@gandalf.local.home> <1403890493.5830.33.camel@marge.simpson.net> <20140627135415.7246e87e@gandalf.local.home> <1403892474.5830.41.camel@marge.simpson.net> <20140627141903.16817c28@gandalf.local.home> <1403926333.5113.12.camel@marge.simpson.net> From: Austin Schuh Date: Fri, 27 Jun 2014 23:20:59 -0700 Message-ID: Subject: Re: Filesystem lockup with CONFIG_PREEMPT_RT To: Mike Galbraith Cc: Steven Rostedt , Thomas Gleixner , Richard Weinberger , LKML , rt-users Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 27, 2014 at 8:32 PM, Mike Galbraith wrote: > On Fri, 2014-06-27 at 18:18 -0700, Austin Schuh wrote: > >> It would be more context switches, but I wonder if we could kick the >> workqueue logic completely out of the scheduler into a thread. Have >> the scheduler increment/decrement an atomic pool counter, and wake up >> the monitoring thread to spawn new threads when needed? That would >> get rid of the recursive pool lock problem, and should reduce >> scheduler latency if we would need to spawn a new thread. > > I was wondering the same thing, and not only for workqueue, but also the > plug pulling. It's kind of a wart to have that stuff sitting in the > hear of the scheduler in the first place, would be nice if it just went > away. When a task can't help itself, you _could_ wake a proxy do that > for you. Trouble is, I can imagine that being a heck of a lot of > context switches with some loads.. and who's gonna help the helper when > he blocks while trying to help? > > -Mike For workqueues, as long as the helper doesn't block on a lock which requires the work queue to be freed up, it will eventually become unblocked and make progress. The helper _should_ only need the pool lock, which will wake the helper back up when it is available again. Nothing should go to sleep in an un-recoverable way with the work pool lock held. To drop the extra context switch, you could have a minimum of 2 worker threads around at all times, and have the management thread start the work and delegate to the next management thread. That thread would then wait for the first thread to block, spawn a new thread, and then start the next piece of work. Definitely a bit more complicated. Austin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/