On Thu, Dec 12, 2013 at 12:10:15PM -0500, Steven Rostedt wrote:
> So if we break up your code above, we have:
>
> raw_spin_lock_irqsave(&head->lock, flags);
> w->task = current;
> if (list_empty(&w->node)) {
> list_add(&w->node, &head->list);
> smp_mb(
On Thu, 12 Dec 2013 11:51:37 -0500
Steven Rostedt wrote:
> >
> > Typically such a barrier comes from set_current_state(), the normal
> > pattern is something like:
> >
> > set_current_state(TASK_UNINTERRUPTIBLE)
> > if (!cond)
> > schedule();
> > __set_current_state(TASK_RUNNING);
> >
On Thu, 12 Dec 2013 17:03:23 +0100
Peter Zijlstra wrote:
> On Thu, Dec 12, 2013 at 09:42:27AM -0500, Steven Rostedt wrote:
> > On Thu, 12 Dec 2013 12:44:47 +0100
> > Peter Zijlstra wrote:
> > > Are these two barriers matched or are they both unmatched and thus
> > > probabyl wrong?
> >
> > Nope
On 13-12-12 06:18 AM, Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 08:06:37PM -0500, Paul Gortmaker wrote:
>> +/*
>> + * Event API
>> + */
>> +#define __swait_event(wq, condition)
>> \
>> +do {
On Thu, Dec 12, 2013 at 09:42:27AM -0500, Steven Rostedt wrote:
> On Thu, 12 Dec 2013 12:44:47 +0100
> Peter Zijlstra wrote:
> > Are these two barriers matched or are they both unmatched and thus
> > probabyl wrong?
>
> Nope, the two are unrelated. The the smp_wmb() is to synchronize with
> the s
On Thu, 12 Dec 2013 16:25:42 +0100 (CET)
Thomas Gleixner wrote:
> On Thu, 12 Dec 2013, Steven Rostedt wrote:
> > On Thu, 12 Dec 2013 09:48:06 -0500
> > Paul Gortmaker wrote:
> >
> > > 1) git mv wait.[ch] --- > cwait.[ch]
> > >make an empty wait.h include cwait.h temporarily
> > >
> > > 2)
On 13-12-12 09:55 AM, Steven Rostedt wrote:
> On Thu, 12 Dec 2013 09:48:06 -0500
> Paul Gortmaker wrote:
>
>> 1) git mv wait.[ch] --- > cwait.[ch]
>>make an empty wait.h include cwait.h temporarily
>>
>> 2) rename all existing functions in cwait.[ch] to have an added
>> "c" prefix (or simi
On Thu, 12 Dec 2013, Steven Rostedt wrote:
> On Thu, 12 Dec 2013 09:48:06 -0500
> Paul Gortmaker wrote:
>
> > 1) git mv wait.[ch] --- > cwait.[ch]
> >make an empty wait.h include cwait.h temporarily
> >
> > 2) rename all existing functions in cwait.[ch] to have an added
> > "c" prefix (or
On Thu, 12 Dec 2013 09:48:06 -0500
Paul Gortmaker wrote:
> 1) git mv wait.[ch] --- > cwait.[ch]
>make an empty wait.h include cwait.h temporarily
>
> 2) rename all existing functions in cwait.[ch] to have an added
> "c" prefix (or similar)
>
>in wait.h, temporarily add a bunch of
On 13-12-12 05:56 AM, Thomas Gleixner wrote:
> On Thu, 12 Dec 2013, Christoph Hellwig wrote:
>
>> On Wed, Dec 11, 2013 at 08:06:37PM -0500, Paul Gortmaker wrote:
>>> From: Thomas Gleixner
>>>
>>> The wait_queue is a swiss army knife and in most of the cases the
>>> full complexity is not needed.
On Thu, 12 Dec 2013 12:44:47 +0100
Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 08:06:37PM -0500, Paul Gortmaker wrote:
> > +/* Adds w to head->task_list. Must be called with head->lock locked. */
> > +static inline void __swait_enqueue(struct swait_queue_head *head,
> > +
On 13-12-12 06:20 AM, Peter Zijlstra wrote:
> On Thu, Dec 12, 2013 at 12:18:09PM +0100, Peter Zijlstra wrote:
>> On Wed, Dec 11, 2013 at 08:06:37PM -0500, Paul Gortmaker wrote:
[...]
>>> +
>>> +unsigned int
>>> +__swake_up(struct swait_queue_head *head, unsigned int state, unsigned int
>>> num)
On Wed, Dec 11, 2013 at 08:06:37PM -0500, Paul Gortmaker wrote:
> +/* Adds w to head->task_list. Must be called with head->lock locked. */
> +static inline void __swait_enqueue(struct swait_queue_head *head,
> +struct swaiter *w)
> +{
> + list_add(&w->node, &head
On Thu, Dec 12, 2013 at 12:18:09PM +0100, Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 08:06:37PM -0500, Paul Gortmaker wrote:
> > +unsigned int
> > +__swake_up_locked(struct swait_queue_head *head, unsigned int state,
> > + unsigned int num)
> > +{
> > + struct swaiter *curr, *nex
On Wed, Dec 11, 2013 at 08:06:37PM -0500, Paul Gortmaker wrote:
> +/*
> + * Event API
> + */
> +#define __swait_event(wq, condition) \
> +do { \
> + DEFINE_SWAITER(__wait);
On Thu, 12 Dec 2013, Christoph Hellwig wrote:
> On Wed, Dec 11, 2013 at 08:06:37PM -0500, Paul Gortmaker wrote:
> > From: Thomas Gleixner
> >
> > The wait_queue is a swiss army knife and in most of the cases the
> > full complexity is not needed. Here we provide a slim version, as
> > it lowers
On Wed, Dec 11, 2013 at 08:06:37PM -0500, Paul Gortmaker wrote:
> From: Thomas Gleixner
>
> The wait_queue is a swiss army knife and in most of the cases the
> full complexity is not needed. Here we provide a slim version, as
> it lowers memory consumption and runtime overhead.
Might it make mo
> --- /dev/null
> +++ b/kernel/swait.c
> @@ -0,0 +1,118 @@
> +/*
> + * Simple waitqueues without fancy flags and callbacks
We should probably have a more detailed description of when to use
simple wait queues verses normal wait queues. These are obviously much
lighter wait, and should be the pref
On Wed, 11 Dec 2013 20:06:37 -0500
Paul Gortmaker wrote:
> From: Thomas Gleixner
>
> The wait_queue is a swiss army knife and in most of the cases the
> full complexity is not needed. Here we provide a slim version, as
> it lowers memory consumption and runtime overhead.
>
> The concept origi
From: Thomas Gleixner
The wait_queue is a swiss army knife and in most of the cases the
full complexity is not needed. Here we provide a slim version, as
it lowers memory consumption and runtime overhead.
The concept originated from RT, where waitqueues are a constant
source of trouble, as we c
20 matches
Mail list logo
