From: Alasdair G Kergon <agk@redhat.com>
To: Kent Overstreet <koverstreet@google.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
linux-kernel@vger.kernel.org, linux-bcache@vger.kernel.org,
akpm@linux-foundation.org, tj@kernel.org, axboe@kernel.dk,
snitzer@redhat.com, agk@redhat.com, neilb@suse.de
Subject: Re: Bcache v. whatever
Date: Wed, 16 Jan 2013 01:29:15 +0000 [thread overview]
Message-ID: <20130116012914.GA27245@agk-dp.fab.redhat.com> (raw)
In-Reply-To: <20130115233347.GD26407@google.com>
On Tue, Jan 15, 2013 at 03:33:47PM -0800, Kent Overstreet wrote:
> I haven't been active on dm-devel, besides the occasional cross
> posting... not sure what activity you're referring to on the dm list,
A caching framework based on dm has been proposed by Joe Thornber (the
original author of dm).
Mike Snitzer is trying to adapt the performance tests for this dm-based
framework to include the latest bcache code that you just posted to
start to give us an idea of the circumstances in which each of them work
well (or badly).
1, Caching is a complicated feature: It's easy to get no benefit or even
a negative benefit from a cache if you use an inappropriate policy or
don't tune it to your I/O patterns.
2. We now have several independent/overlapping implementations of this
type of caching. Comparing and contrasting them should help us to tease
out the critical design elements and optimisations and decide which of
them together or separately (or some hybrid) would enable the kernel to
support the widest range of situations users require with the minimum
of code and complexity.
3. We all want to move quickly now, perhaps even with something in the
next merge window if we can or otherwise the one after that.
Alasdair
next prev parent reply other threads:[~2013-01-16 1:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-14 22:32 Kent Overstreet
2013-01-15 1:49 ` Greg KH
2013-01-15 21:18 ` Kent Overstreet
2013-01-15 22:50 ` Greg KH
2013-01-15 9:20 ` James Bottomley
2013-01-15 20:59 ` Kent Overstreet
2013-01-15 23:15 ` James Bottomley
2013-01-15 23:33 ` Kent Overstreet
2013-01-16 1:29 ` Alasdair G Kergon [this message]
2013-01-17 23:43 ` Mike Snitzer
2013-01-15 21:25 ` [PATCH 1/4] Revert "rw_semaphore: remove up/down_read_non_owner" Kent Overstreet
2013-01-15 21:25 ` [PATCH 2/4] Export get_random_int() Kent Overstreet
2013-01-15 21:25 ` [PATCH 3/4] Export blk_fill_rwbs() Kent Overstreet
2013-02-01 3:48 ` Steven Rostedt
2013-02-01 3:57 ` Li Zefan
2013-02-01 4:06 ` Steven Rostedt
2013-01-15 21:25 ` [PATCH 4/4] Export __lockdep_no_validate__ Kent Overstreet
2013-04-25 23:17 ` Bcache v. whatever Andrew Morton
2013-04-26 19:46 ` Kent Overstreet
2013-04-26 20:24 ` Andrew Morton
2013-04-26 20:54 ` Kent Overstreet
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=20130116012914.GA27245@agk-dp.fab.redhat.com \
--to=agk@redhat.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=koverstreet@google.com \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=snitzer@redhat.com \
--cc=tj@kernel.org \
/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
all inboxes | Powered by JetHome®