On Wed, Jan 14, 2015 at 10:01:02AM -0500, Steven Rostedt wrote:
> Then why even bother with the wake_up_state, and not just call
> wake_up_process()?
Ah indeed. TASK_NORMAL should be fine for all.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
On Wed, 14 Jan 2015 15:31:02 +0100
Peter Zijlstra wrote:
> On Wed, Jan 14, 2015 at 09:18:49AM -0500, Steven Rostedt wrote:
> > > +/*
> > > + * Does not allow usage from IRQ disabled, since we must be able to
> > > + * release IRQs to guarantee bounded hold time.
> >
> > Actually we (-rt people)
On Wed, Jan 14, 2015 at 09:18:49AM -0500, Steven Rostedt wrote:
> > +/*
> > + * Does not allow usage from IRQ disabled, since we must be able to
> > + * release IRQs to guarantee bounded hold time.
>
> Actually we (-rt people) don't care if it's done with irq disabled, as
> long is it was disabled
On Wed, 14 Jan 2015 11:38:34 +0100
Peter Zijlstra wrote:
>
>
> So I had a look at this yesterday and came up with the below --
> completely untested etc.
>
> Now in order to compile test I meant to convert the completion code and
> ran head first into complete_all; it uses spin_lock_irqsave()
So I had a look at this yesterday and came up with the below --
completely untested etc.
Now in order to compile test I meant to convert the completion code and
ran head first into complete_all; it uses spin_lock_irqsave() which
means it can be used from IRQ context. Now if you look at
__swake_u
On Mon, 20 Oct 2014 12:05:42 -0400
Paul Gortmaker wrote:
> > No. You move the items off the main list head and add it to the local
> > list and they never go back. Just start processing that local list.
> > Anything added to the main list after that will not get woken up by
> > that current wake
[Re: [PATCH 3/7] wait.[ch]: Introduce the simple waitqueue (swait)
implementation] On 20/10/2014 (Mon 11:40) Steven Rostedt wrote:
> On Mon, 20 Oct 2014 11:21:44 -0400
> Paul Gortmaker wrote:
>
> > > Right, and we should slap Paul for not showing up for it ;-)
> >
On Mon, 20 Oct 2014 11:21:44 -0400
Paul Gortmaker wrote:
> > Right, and we should slap Paul for not showing up for it ;-)
>
> And miss turkey day? ;-)
Replace it with Alt Beer day!
> I'd like to hear more details on what you had in mind here, so I don't
> go chasing down the wrong road. So
[Re: [PATCH 3/7] wait.[ch]: Introduce the simple waitqueue (swait)
implementation] On 18/10/2014 (Sat 19:05) Steven Rostedt wrote:
> On Sat, 2014-10-18 at 23:34 +0200, Peter Zijlstra wrote:
>
> > Same comment as before, that is an unbounded loop in a non preemptible
> > sec
[Re: [PATCH 3/7] wait.[ch]: Introduce the simple waitqueue (swait)
implementation] On 18/10/2014 (Sat 23:34) Peter Zijlstra wrote:
> On Fri, Oct 17, 2014 at 08:22:58PM -0400, Paul Gortmaker wrote:
> > @@ -75,6 +123,32 @@ static void __cwake_up_common(struct cwait_head *q,
> > un
On Sat, 2014-10-18 at 23:34 +0200, Peter Zijlstra wrote:
> Same comment as before, that is an unbounded loop in a non preemptible
> section and therefore violates RT design principles.
>
> We actually did talk about ways of fixing that.
Right, and we should slap Paul for not showing up for it ;-
On Fri, Oct 17, 2014 at 08:22:58PM -0400, Paul Gortmaker wrote:
> @@ -75,6 +123,32 @@ static void __cwake_up_common(struct cwait_head *q,
> unsigned int mode,
> }
> }
>
> +static void __swake_up_common(struct swait_head *q, unsigned int mode,
> + int nr_exclusive
The existing wait queue support has support for custom wake up call
backs, wake flags, wake key (passed to call back) and exclusive
flags that allow wakers to be tagged as exclusive, for limiting
the number of wakers.
In a lot of cases, none of these features are used, and hence we
can benefit fro
13 matches
Mail list logo
