public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jarek Poplawski <jarkao2@o2.pl>,
	Max Krasnyansky <maxk@qualcomm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] workqueues: insert_work: use "list_head *" instead of "int tail"
Date: Thu, 12 Jun 2008 19:01:14 +0200	[thread overview]
Message-ID: <1213290074.31518.136.camel@twins> (raw)
In-Reply-To: <20080612165550.GA12183@tv-sign.ru>

On Thu, 2008-06-12 at 20:55 +0400, Oleg Nesterov wrote:
> On 06/12, Oleg Nesterov wrote:
> >
> > insert_work() inserts the new work_struct before or after cwq->worklist,
> > depending on the "int tail" parameter. Change it to accept "list_head *"
> > instead, this shrinks .text a bit and allows us to insert the barrier
> > after specific work_struct.
> 
> This allows us to implement
> 
> 	int flush_work(struct work_struct *work)
> 	{
> 		struct cpu_workqueue_struct *cwq;
> 		struct list_head *head;
> 		struct wq_barrier barr;
> 
> 		cwq = get_wq_data(work);
> 		if (!cwq)
> 			return 0;
> 
> 		head = NULL;
> 		spin_lock_irq(&cwq->lock);
> 		if (!list_empty(&work->entry)) {
> 			smp_rmb();
> 			/*
> 			 * ---- FAT COMMENT ----
> 			 */
> 			if (cwq == get_wq_data(work))
> 				head = work->entry.next;
> 		} else if (cwq->current_work == work) {
> 			head = cwq->worklist.next;
> 		}
> 
> 		if (head)
> 			insert_wq_barrier(cwq, &barr, head);
> 		spin_unlock_irq(&cwq->lock);
> 
> 		if (!head)
> 			return 0;
> 		wait_for_completion(&barr.done);
> 		return 1;
> 	}
> 
> suggested by Peter. It only waits for selected work_struct.
> 
> I doubt it will have a lot of users though. In most cases we need
> cancel_work_sync() and nothing more.

Are there cases where we dynamically allocate work structs and queue
them and then forget about them? In such cases we'd need something a
little more complex as we don't have work pointers to flush or cancel.

Hence that idea of flush context and completions.

Aside from that, this seems like a fine idea. :-)


  reply	other threads:[~2008-06-12 17:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-12 16:51 [PATCH] workqueues: insert_work: use "list_head *" instead of "int tail" Oleg Nesterov
2008-06-12 16:55 ` Oleg Nesterov
2008-06-12 17:01   ` Peter Zijlstra [this message]
2008-06-12 17:44     ` Oleg Nesterov
2008-06-12 18:38       ` Peter Zijlstra
2008-06-13 14:26         ` Oleg Nesterov
2008-06-13 14:43           ` Peter Zijlstra
2008-06-13 15:17             ` Oleg Nesterov
2008-06-13 15:32               ` Peter Zijlstra
2008-06-24  5:41                 ` Max Krasnyansky
2008-06-12 22:24   ` Jarek Poplawski
2008-06-13 10:13     ` Jarek Poplawski

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=1213290074.31518.136.camel@twins \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=jarkao2@o2.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxk@qualcomm.com \
    --cc=oleg@tv-sign.ru \
    /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