All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: Akira Hayakawa <ruby.wktk@gmail.com>
Cc: gregkh@linuxfoundation.org, dm-devel@redhat.com,
	driverdev-devel@linuxdriverproject.org, thornber@redhat.com
Subject: Re: [PATCH v2] staging: writeboost: Add dm-writeboost
Date: Thu, 11 Dec 2014 10:26:26 -0500	[thread overview]
Message-ID: <20141211152626.GA8196@redhat.com> (raw)
In-Reply-To: <54883195.1060304@gmail.com>

On Wed, Dec 10 2014 at  6:42am -0500,
Akira Hayakawa <ruby.wktk@gmail.com> wrote:

> This patch adds dm-writeboost to staging tree.
> 
> dm-writeboost is a log-structured SSD-caching driver.
> It caches data in log-structured way on the cache device
> so that the performance is maximized.
> 
> The merit of putting this driver in staging tree is
> to make it possible to get more feedback from users
> and polish the codes.
> 
> Signed-off-by: Akira Hayakawa <ruby.wktk@gmail.com>

Joe Thornber Nacked this from going into staging based on his further
review of the code.  On the basis that you should _not_ be copying all
pages associated with each bio into an in-core buffer.  Have you
addressed that fundamental problem?

But taking a step back: Why do you think going into staging actually
helps you?  Anyone who is willing to test this code should be able to
apply a patch to their kernel.  Having to feed changes to Greg to
deliver updates to any early consumers of this _EXPERIMENTAL_ target
seems misplaced when you consider that Joe has detailed important
fixes, capabilties and tools that need addressing before anyone should
trust their production data to dm-writeboost.

I think you're completely missing that you are pushing _hard_ for this
target to go upstream before it is actually ready.  In doing so you're
so hung up on that "upstream" milestone that you cannot appreciate the
reluctance that Joe and I have given the quantity of code you're pushing
-- especially when coupled with the limited utility of dm-writeboost in
comparison with full featured upstream drivers like dm-cache and bcache.

As for this v2, you didn't detail what you changed (I can obviously
apply v1 and then v2 to see the difference but a brief summary would be
helpful in general when you revise a patch)

But one inline comment:

> diff --git a/drivers/staging/writeboost/TODO b/drivers/staging/writeboost/TODO
> new file mode 100644
> index 0000000..761a9fe
> --- /dev/null
> +++ b/drivers/staging/writeboost/TODO
> @@ -0,0 +1,52 @@
> +TODO:
> +
> +- Get the GitExtract test so it's performance is similar to raw spindle.

No, the whole point of a write cache is to improve performance.  You
should be trying to surpass the performance of the raw spindle.

  reply	other threads:[~2014-12-11 15:26 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-10 11:42 [PATCH v2] staging: writeboost: Add dm-writeboost Akira Hayakawa
2014-12-11 15:26 ` Mike Snitzer [this message]
2014-12-12  0:42   ` Akira Hayakawa
2014-12-12  9:12     ` [dm-devel] " Bart Van Assche
2014-12-12  9:35       ` Akira Hayakawa
2014-12-12  9:35         ` Akira Hayakawa
2014-12-12 11:41         ` Bart Van Assche
2014-12-12 22:18           ` Spelic
2014-12-13  7:08             ` Jianjian Huo
2014-12-12 14:24     ` Joe Thornber
2014-12-12 14:24       ` Joe Thornber
2014-12-12 15:09       ` Akira Hayakawa
2014-12-12 15:09         ` Akira Hayakawa
2014-12-13  6:45         ` [dm-devel] " Jianjian Huo
2014-12-13  6:45           ` Jianjian Huo
2014-12-13 14:07           ` Akira Hayakawa
2014-12-13 14:07             ` Akira Hayakawa
2014-12-14  2:12             ` Akira Hayakawa
2014-12-14  2:12               ` Akira Hayakawa
2014-12-14  2:46             ` Jianjian Huo
2014-12-14  2:46               ` Jianjian Huo
2014-12-14  3:22               ` Akira Hayakawa
2014-12-14  3:22                 ` Akira Hayakawa
2014-12-14  3:00         ` Akira Hayakawa
2014-12-14  3:00           ` Akira Hayakawa

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=20141211152626.GA8196@redhat.com \
    --to=snitzer@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=driverdev-devel@linuxdriverproject.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=ruby.wktk@gmail.com \
    --cc=thornber@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 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.