All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarek Poplawski <jarkao2@o2.pl>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Chinner <dgc@sgi.com>, David Howells <dhowells@redhat.com>,
	Gautham Shenoy <ego@in.ibm.com>, Ingo Molnar <mingo@elte.hu>,
	Srivatsa Vaddagiri <vatsa@in.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] make-cancel_rearming_delayed_work-reliable-fix
Date: Tue, 8 May 2007 15:07:48 +0200	[thread overview]
Message-ID: <20070508130748.GF1772@ff.dom.local> (raw)
In-Reply-To: <20070508120221.GA968@tv-sign.ru>

On Tue, May 08, 2007 at 04:02:21PM +0400, Oleg Nesterov wrote:
> On 05/08, Jarek Poplawski wrote:
> >
> > On Mon, May 07, 2007 at 02:34:20PM +0400, Oleg Nesterov wrote:
> > > On 05/07, Jarek Poplawski wrote:
...
> I am strongly against adding many different variants of cancel_xxx().
> With this patch the API is simple
> 
> 	- cancel_delayed_work() stops the timer
> 
> 	- cancel_rearming_delayed_work() stops the timer and work,
> 	  doesn't need cancel_work_sync/flush_workqueue

But most often there is a simple rearming (but not neccessarily
always) work for which the first is not enough and the second
an overkill (especially with system/workqueues loaded).

> When work->func() re-arms itself, both queue_work() and queue_delayed_work()
> may change CPU if CPU_DOWN_xxx happens. Note that this is possible
> even if we use freezer for cpu-hotplug, because the timer migrates to
> another CPU anyway.

Thanks for explanation - I try to think about this.
 
> >                                I'm not sure what exactly place
> > did you mean - if spinlocking in wait_on_work - maybe it's
> > a sign this place isn't optimal too: it seems to me, this all
> > inserting/waiting for completion could be done under existing
> > locks e.g. in run_workqueue (maybe with some flag?).
> 
> Sorry, can't understand this. Inserting uses existing lock, namely
> cwq->lock.

I meant held locks - maybe e.g. after seeing some flag set (or some
other global/per_cpu/atomic/whatever variable) in a processed work
insert_wq_barrier could be done in already locked place. Or maybe
the whole idea of these completions should be rethinked, for
something lighter (i.e. lockless)?

> 
> Just in case, I think wait_on_cpu_work() can check ->current_work without
> cwq->lock, but I am not sure yet. We can remove unneeded "new |= " from
> set_wq_data(), we can do a couple of other optimizations. However, there
> are already _a lot_ of workqueue changes in -mm tree. We can do this later.
> Right now my only concern is correctness.

I agree 100% - it's -mm, the old way is working, so why hurry?

Jarek P.

  reply	other threads:[~2007-05-08 13:01 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-03 20:42 [PATCH] make cancel_rearming_delayed_work() reliable Oleg Nesterov
2007-05-04  1:15 ` Andrew Morton
2007-05-04 17:09   ` Oleg Nesterov
2007-05-05 21:32   ` [PATCH] make-cancel_rearming_delayed_work-reliable-fix Oleg Nesterov
2007-05-07 10:31     ` Jarek Poplawski
2007-05-07 10:34       ` Oleg Nesterov
2007-05-07 11:55         ` Anton Vorontsov
2007-05-07 11:33           ` Oleg Nesterov
2007-05-08  9:16         ` Jarek Poplawski
2007-05-08 12:02           ` Oleg Nesterov
2007-05-08 13:07             ` Jarek Poplawski [this message]
2007-05-08  7:15 ` [PATCH] make cancel_rearming_delayed_work() reliable Jarek Poplawski
2007-05-08 12:31   ` Oleg Nesterov
2007-05-08 13:56     ` Jarek Poplawski
2007-05-08 14:05       ` Oleg Nesterov
2007-05-08 14:32         ` Jarek Poplawski
2007-05-08 14:12       ` Jarek Poplawski
2007-05-11 13:55 ` Tejun Heo
2007-05-11 13:47   ` Oleg Nesterov
2007-05-11 15:19     ` Tejun Heo
2007-05-11 14:53       ` Oleg Nesterov
2007-05-12  5:50         ` Tejun Heo
2007-05-13 19:27           ` Oleg Nesterov
2007-05-13 20:16             ` Tejun Heo
2007-05-13 21:25               ` Oleg Nesterov
2007-05-14 19:44               ` Oleg Nesterov
2007-05-15  8:26                 ` Tejun Heo
2007-05-15 13:09                   ` Jarek Poplawski
2007-05-15 22:08                     ` Oleg Nesterov
2007-05-16  5:21                       ` Jarek Poplawski
2007-05-15 22:00                   ` Oleg Nesterov
2007-05-16 11:25                     ` Tejun Heo
2007-05-16 18:52                       ` Oleg Nesterov
2007-05-17  9:36                         ` Tejun Heo
2007-05-18  7:35                         ` Jarek Poplawski
2007-05-18  8:13                           ` Jarek Poplawski
2007-05-18 13:33                           ` Tejun Heo
2007-05-21  7:00                             ` Jarek Poplawski
2007-05-21  8:59                               ` Tejun Heo
2007-05-21 10:10                                 ` 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=20070508130748.GF1772@ff.dom.local \
    --to=jarkao2@o2.pl \
    --cc=akpm@linux-foundation.org \
    --cc=dgc@sgi.com \
    --cc=dhowells@redhat.com \
    --cc=ego@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@tv-sign.ru \
    --cc=vatsa@in.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.