On Tue, 2007-07-31 at 10:26 -0400, Gregory Haskins wrote: > >>> On Tue, Jul 31, 2007 at 5:25 AM, in message <[EMAIL PROTECTED]>, > Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > as far as the prioritization of function calls goes, _that_ makes sense, > > but it should not be a separate API but should be done to our normal > > workqueue APIs. That not only extends the effects of priorities to all > > current workqueue using kernel subsystems, but also keeps the API more > > unified. We really dont want to have too many -rt specific APIs. > > I just took a look at the workqueue code . There are two immediate problems > that I see: > > 1) cpu_workqueue_struct->lock is a spinlock_t and will need to become a > raw_spinlock_t > > 2) The lock is held for the duration of the execution of workqueue items. We > will need to revamp this such that new workqueue items can still be queued > even while executing others. >
Duh...scratch #2. I missed the unlock/lock sequence. :P #1 is still a potential problem, as is the use of completion variables. -Greg - 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/
