linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH 3/7] wait.[ch]: Introduce the simple waitqueue (swait) implementation
Date: Sat, 18 Oct 2014 23:34:17 +0200	[thread overview]
Message-ID: <20141018213417.GE23531@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <1413591782-23453-4-git-send-email-paul.gortmaker@windriver.com>

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)
> +{
> +	struct swait *curr, *next;
> +	int woken = 0;
> +
> +	list_for_each_entry_safe(curr, next, &q->task_list, node) {
> +		if (wake_up_state(curr->task, mode)) { /* <-- calls ttwu() */
> +			__remove_swait(q, curr);
> +			curr->task = NULL;
> +			/*
> +			 * The waiting task can free the waiter as
> +			 * soon as curr->task = NULL is written,
> +			 * without taking any locks. A memory barrier
> +			 * is required here to prevent the following
> +			 * store to curr->task from getting ahead of
> +			 * the dequeue operation.
> +			 */
> +			smp_wmb();
> +			if (++woken == nr_exclusive)
> +				break;
> +		}
> +
> +	}
> +}
> +
>  /**
>   * __cwake_up - wake up threads blocked on a waitqueue.
>   * @q: the complex waitqueue
> @@ -96,6 +170,19 @@ void __cwake_up(struct cwait_head *q, unsigned int mode, int nr_exclusive,
>  }
>  EXPORT_SYMBOL(__cwake_up);
>  
> +void __swake_up(struct swait_head *q, unsigned int mode, int nr_exclusive)
> +{
> +	unsigned long flags;
> +
> +	if (!swait_active(q))
> +		return;
> +
> +	raw_spin_lock_irqsave(&q->lock, flags);
> +	__swake_up_common(q, mode, nr_exclusive);
> +	raw_spin_unlock_irqrestore(&q->lock, flags);
> +}
> +EXPORT_SYMBOL(__swake_up);

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.

Also, I'm not entirely sure we want to do the cwait thing, it looks
painful.

  reply	other threads:[~2014-10-18 21:34 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-18  0:22 [PATCH v2 0/7] simple wait queue support (from -rt) Paul Gortmaker
2014-10-18  0:22 ` [PATCH 1/7] wait.h: mark complex wait functions to prepare for simple wait Paul Gortmaker
2014-10-18  0:22 ` [PATCH 2/7] wait.c: " Paul Gortmaker
2014-10-18  0:22 ` [PATCH 3/7] wait.[ch]: Introduce the simple waitqueue (swait) implementation Paul Gortmaker
2014-10-18 21:34   ` Peter Zijlstra [this message]
2014-10-18 23:05     ` Steven Rostedt
2014-10-20 15:21       ` Paul Gortmaker
2014-10-20 15:40         ` Steven Rostedt
2014-10-20 16:05           ` Paul Gortmaker
2014-10-20 16:47             ` Steven Rostedt
2014-10-20 13:44     ` Paul Gortmaker
2015-01-14 10:38   ` Peter Zijlstra
2015-01-14 14:18     ` Steven Rostedt
2015-01-14 14:31       ` Peter Zijlstra
2015-01-14 15:01         ` Steven Rostedt
2015-01-14 15:29           ` Peter Zijlstra
2014-10-18  0:22 ` [PATCH 4/7] sched/completion: convert completions to use simple wait queues Paul Gortmaker
2014-10-18  0:23 ` [PATCH 5/7] rcu: use simple wait queues where possible in rcutree Paul Gortmaker
2014-10-18  0:23 ` [PATCH 6/7] simplewait: don't run a possibly infinite number of wake under raw lock Paul Gortmaker
2014-10-18  0:23 ` [PATCH 7/7] simplewait: do we make barriers reflect what was in use in -rt? Paul Gortmaker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141018213417.GE23531@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).