Linux Device Mapper development
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: dm-devel@redhat.com, Alasdair G Kergon <agk@redhat.com>
Subject: Re: dm snapshot: stop merging using a completion
Date: Mon, 7 Dec 2009 09:01:45 -0500	[thread overview]
Message-ID: <20091207140145.GA8917@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0912070621500.15072@hs20-bc2-1.build.redhat.com>

On Mon, Dec 07 2009 at  6:22am -0500,
Mikulas Patocka <mpatocka@redhat.com> wrote:

> 
> 
> On Sun, 6 Dec 2009, Mike Snitzer wrote:
> 
> > On Sat, Dec 05 2009 at  9:01pm -0500,
> > Mikulas Patocka <mpatocka@redhat.com> wrote:
> > 
> > > On Sat, 5 Dec 2009, Mike Snitzer wrote:
> > > 
> > > > Switch stop_merge() from using a busy loop to a completion event.
> > > > 
> > > > stop_merge() now requests merging be shutdown using the
> > > > 'merge_completion' pointer (instead of the 'merge_shutdown' flag).  This
> > > > is accomplished by testing if 'merge_completion' is not NULL in
> > > > snapshot_merge_process().  stop_merge() allocates its completion on the
> > > > stack and assigns it to the 'merge_completion' pointer in the snapshot.
> > > > 'merge_completion' is protected by the snapshot's lock.
> > > > 
> > > > Also changed the 'merge_running' flag from int to atomic_t.
> > > 
> > > No, there's a bug:
> > > 
> > > >  static void stop_merge(struct dm_snapshot *s)
> > > >  {
> > > > -	while (s->merge_running) {
> > > > -		s->merge_shutdown = 1;
> > > > -		msleep(1);
> > > > +	DECLARE_COMPLETION_ONSTACK(merge_stopped);
> > > > +	if (atomic_read(&s->merge_running)) {
> > > 
> > > --- if the merge stops exactly at this point (because it gets finished or 
> > > because of an i/o error), we are waiting for a completion that will be 
> > > never signalled.
> > 
> > Yes, valid point.  But for this rare corner case we could just use
> > wait_for_completion_timeout() with a fairly large timeout; like 30 sec?
> > That actually isn't a great option (racey)...
> > 
> > How about if the 'shut:' code paths also checked for s->merge_completion
> > and complete() if it is not NULL?  Which means that check and related
> > complete() code would become a function.
> > 
> > > > +		down_write(&s->lock);
> > > > +		s->merge_completion = &merge_stopped;
> > > > +		up_write(&s->lock);
> > > > +		wait_for_completion(&merge_stopped);
> > > >  	}
> > > > -	s->merge_shutdown = 0;
> > > >  }
> > > >  
> > > >  /*
> > > 
> > > For Alasdair: do you get the problem? If I write it with msleep() 
> > > correctly, you keep on complaining how unclean it is --- if it is written 
> > > with completions and it is wrong (because they are just harder to use 
> > > correctly than simple variables and msleep), you tend to support it. Now 
> > > you see in practice how complex constructs tend to trigger bugs.
> > > 
> > > Mike: I thought that the completion would be in struct dm_snapshot. But 
> > > maybe, try it with wait_on_bit / wake_up_bit / test_bit / set_bit etc., it 
> > > may be easier than completions.
> > 
> > I can look at it; but I think using a completion can work.
> > 
> > Mike
> 
> Here it is with bits:

OK, looks good; especially in that we can reuse 'bits' for other things
as needed.

Acked-by: Mike Snitzer <snitzer@redhat.com>

  reply	other threads:[~2009-12-07 14:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-05 18:24 [PATCH] dm snapshot: stop merging using a completion Mike Snitzer
2009-12-06  2:01 ` Mikulas Patocka
2009-12-06  6:43   ` Mike Snitzer
2009-12-07 11:22     ` Mikulas Patocka
2009-12-07 14:01       ` Mike Snitzer [this message]
2009-12-07 15:45         ` dm snapshot: eliminate busy waiting when stopping merge [Was: Re: dm snapshot: stop merging using a completion] Mike Snitzer

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=20091207140145.GA8917@redhat.com \
    --to=snitzer@redhat.com \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=mpatocka@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox