linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: Christoph Hellwig <hch@lst.de>, Shaohua Li <shli@fb.com>
Cc: linux-raid@vger.kernel.org, Kernel-team@fb.com, dan.j.williams@intel.com
Subject: Re: [PATCH 02/12] raid5-cache: free I/O units earlier
Date: Tue, 15 Sep 2015 09:00:31 +0200	[thread overview]
Message-ID: <87d1xk6ub4.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <1442038638-6947-3-git-send-email-hch@lst.de>

[-- Attachment #1: Type: text/plain, Size: 3721 bytes --]

Christoph Hellwig <hch@lst.de> writes:

> There is no good reason to keep the I/O unit structures around after the
> stripe has been written back to the RAID array.  The only information
> we need is the log sequence number, and the checkpoint offset of the
> highest successfull writeback.  Store those in the log structure, and
> free the IO units from __r5l_stripe_write_finished.
>
> Besides simplifying the code this also avoid having to keep the allocation
> for the I/O unit around for a potentially long time as superblock updates
> that checkpoint the log do not happen very often.

This only saves the allocation for two I/O units doesn't it?  So not a
big saveding, but still a good clean-up.

>
> This also fixes the previously incorrect calculation of 'free' in
> r5l_do_reclaim as a side effect: previous if took the last unit which
> isn't checkpointed into account.

It took me a while to see that - so just to be sure I understand.

There is a list of I/O units which have been completely written to the
log and to the RAID.  The last one of these is used as a marker for the
start of the log, so it cannot be freed yet.  All the earlier ones can
be freed.
The previous code added up the sizes of all of the units in this list,
so it incorrectly included that last unit.
Your new code calculates the difference between the start of the first
unit and the start of the last unit, and so correctly excluded the last
unit from the free space calculation.

Did I get that right?

> @@ -690,60 +675,41 @@ static void r5l_do_reclaim(struct r5l_log *log)
>  	 * shouldn't reuse space of an unreclaimable io_unit
>  	 * */
>  	while (1) {
> -		struct list_head *target_list = NULL;
> -
> -		while (!list_empty(&log->stripe_end_ios)) {
> -			io = list_first_entry(&log->stripe_end_ios,
> -				struct r5l_io_unit, log_sibling);
> -			list_move_tail(&io->log_sibling, &list);
> -			free += r5l_ring_distance(log, io->log_start,
> -						io->log_end);
> -		}
> -
> -		if (free >= reclaim_target ||
> +		reclaimable = r5l_reclaimable_space(log);
> +		if (reclaimable >= reclaim_target ||
>  		    (list_empty(&log->running_ios) &&
>  		     list_empty(&log->io_end_ios) &&
>  		     list_empty(&log->flushing_ios) &&
>  		     list_empty(&log->flushed_ios)))
>  			break;
>  
> -		/* Below waiting mostly happens when we shutdown the raid */
> -		if (!list_empty(&log->flushed_ios))
> -			target_list = &log->flushed_ios;
> -		else if (!list_empty(&log->flushing_ios))
> -			target_list = &log->flushing_ios;
> -		else if (!list_empty(&log->io_end_ios))
> -			target_list = &log->io_end_ios;
> -		else if (!list_empty(&log->running_ios))
> -			target_list = &log->running_ios;
> -
> -		r5l_kick_io_unit(log);
> +		md_wakeup_thread(log->rdev->mddev->thread);
> +		wait_event_lock_irq(log->iounit_wait,
> +				    r5l_reclaimable_space(log) > reclaimable,
> +				    log->io_list_lock);
>  	}

This is ringing warning bells....  I'm not sure it's wrong, but I'm not
sure it is right.
I feel that if the thread gets woken and finds that
r5l_reclaimable_space is still too low, it should wake up the thread
again, just in case.
Also, it should test against reclaim_target, not reclaimable, shouldn't
it?

Instead of a wait_event_lock_irq inside a loop, could we just have a
wake_event_*??

wait_event_lock_irq_cmd(log->iounit_wait,
                        r5l_reclaimable_space(log) >= reclaim_target ||
                        (list_empty() && .... list_empty()),
                        log->io_list_lock,
                        md_wakeup_thread(log->rdev->mddev->thread));

??


Otherwise I like it.  Thanks.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

  reply	other threads:[~2015-09-15  7:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-12  6:17 raid5-cache I/O path improvements V2 Christoph Hellwig
2015-09-12  6:17 ` [PATCH 01/12] raid5-cache: port to 4.3-rc Christoph Hellwig
2015-09-12  6:17 ` [PATCH 02/12] raid5-cache: free I/O units earlier Christoph Hellwig
2015-09-15  7:00   ` Neil Brown [this message]
2015-09-17  1:50     ` Christoph Hellwig
2015-09-15  8:07   ` Neil Brown
2015-09-17  1:48     ` Christoph Hellwig
2015-09-12  6:17 ` [PATCH 03/12] raid5-cache: rename flushed_ios to finished_ios Christoph Hellwig
2015-09-12  6:17 ` [PATCH 04/12] raid5-cache: factor out a helper to run all stripes for an I/O unit Christoph Hellwig
2015-09-12  6:17 ` [PATCH 05/12] raid5-cache: use FUA writes for the log Christoph Hellwig
2015-09-12  6:17 ` [PATCH 06/12] raid5-cache: clean up r5l_get_meta Christoph Hellwig
2015-09-12  6:17 ` [PATCH 07/12] raid5-cache: refactor bio allocation Christoph Hellwig
2015-09-12  6:17 ` [PATCH 08/12] raid5-cache: take rdev->data_offset into account early on Christoph Hellwig
2015-09-12  6:17 ` [PATCH 09/12] raid5-cache: inline r5l_alloc_io_unit into r5l_new_meta Christoph Hellwig
2015-09-12  6:17 ` [PATCH 10/12] raid5-cache: new helper: r5_reserve_log_entry Christoph Hellwig
2015-09-12  6:17 ` [PATCH 11/12] raid5-cache: small log->seq cleanup Christoph Hellwig
2015-09-12  6:17 ` [PATCH 12/12] raid5-cache: use bio chaining Christoph Hellwig
2015-09-14 19:11 ` raid5-cache I/O path improvements V2 Shaohua Li
2015-09-15  7:23   ` Neil Brown
2015-09-15 21:54     ` Shaohua Li
2015-09-17  1:53       ` Christoph Hellwig
2015-09-28 14:01       ` Christoph Hellwig
2015-09-30  5:39         ` Neil Brown
2015-09-30 15:00           ` Christoph Hellwig

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=87d1xk6ub4.fsf@notabene.neil.brown.name \
    --to=neilb@suse.de \
    --cc=Kernel-team@fb.com \
    --cc=dan.j.williams@intel.com \
    --cc=hch@lst.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=shli@fb.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;
as well as URLs for NNTP newsgroup(s).