On Mon, Apr 15, 2013 at 09:55:39AM -0400, Mike Snitzer wrote:
On Sat, Apr 13 2013 at 3:33pm -0400,
Mike Snitzer snit...@redhat.com wrote:
On Sat, Apr 13 2013 at 12:09pm -0400,
Joe Thornber thorn...@redhat.com wrote:
Hi Darrick,
On Thu, Apr 11, 2013 at 12:22:39AM -0700
Hi Darrick,
On Thu, Apr 11, 2013 at 12:22:39AM -0700, Darrick J. Wong wrote:
Hi all,
Lately I've been having some fun playing with bcache, dmcache, and enhanceio.
I pushed some tweaks to the mq policy today to my thin-dev tree. They
show some improvements to these fio based tests.
In
Hi Darrick,
On Fri, Mar 22, 2013 at 01:11:51PM -0700, Darrick J. Wong wrote:
The new writethrough strategy for dm-cache issues a bio to the origin device,
remaps the bio to the cache device, and issues the bio to the cache device.
However, the block layer modifies bi_sector and bi_size, so we
On Sun, Jul 28, 2013 at 11:42:57AM +0900, Akira Hayakawa wrote:
I wrote an introduction slide which is available in URL below:
https://github.com/akiradeveloper/dm-lc/blob/develop/what-is-dm-lc.pdf
access the page and click view raw.
This is nicely orthogonal to dm-cache.
dm-cache tries to
On Thu, Oct 03, 2013 at 10:27:54PM +0900, Akira Hayakawa wrote:
dm-cache doesn't have this problem, if you overwrite the same piece of
data again and again, it goes to the cache device.
It is not a bug but should/can be optimized.
Below is the cache hit path for writes.
writeboost
Hi Matias,
This looks really interesting and I'd love to get involved. Do you
have any recommendations for what hardware I should pick up?
- Joe
On Thu, Mar 20, 2014 at 11:32:17PM -0700, Matias Bjørling wrote:
Hi,
Users that have custom firmware SSDs, may choose to expose their flash
On Tue, Jun 11, 2013 at 03:05:07PM +, OS Engineering wrote:
...
Dm-cache commits on-disk metadata every time a REQ_SYNC or REQ_FUA
bio is written. If no such requests are made then it commits
metadata once every second. If power is lost, it may lose some
recent writes.
Not true (though
On Wed, May 08, 2013 at 06:05:26PM -0400, Mike Snitzer wrote:
I'll defer to Joe on this but I think sync_metadata() is pretty heavy to
be doing every 'dmsetup info'. BTW, with just dm_cache_commit() the
superblock fields aren't stale; only the on-disk hints are.
Agreed, the hints are v.
On Thu, May 09, 2013 at 01:44:38PM -0700, Darrick J. Wong wrote:
When userspace queries dmcache for stats info, we should ensure that all the
metadata gets flushed out of memory to disk. The current code neglects to
update the disk copy of the hit/miss counters.
Nack, I'm afraid. The commit
On Thu, May 09, 2013 at 01:47:51PM -0700, Darrick J. Wong wrote:
Create a new 'flush' message that causes the dmcache to write all of its
metadata out to disk. This enables us to ensure that the disk reflects
whatever's in memory without having to tear down the cache device. This helps
me in
On Thu, Sep 26, 2013 at 01:43:25PM +1000, Dave Chinner wrote:
On Tue, Sep 24, 2013 at 09:20:50PM +0900, Akira Hayakawa wrote:
* Deferring ACK for barrier writes
Barrier flags such as REQ_FUA and REQ_FLUSH are handled lazily.
Immediately handling these bios badly slows down writeboost.
It
On Tue, May 20, 2014 at 12:53:56PM +0900, na...@elisp.net wrote:
In era_ctr(), era-md remain NULL until it's set after metadata_open().
On the other hand, era_destroy() assume era-md is non-NULL and it is
called by era_ctr() before initializing the value.
Thanks. This change went into my tree
: Joe Thornber e...@redhat.com
Date: Fri Jun 27 15:49:29 2014 +0100
[dm-io] Fix a race condition in the wake up code for sync_io
There's a race condition between the atomic_dec_and_test(io-count)
in dec_count() and the waking of the sync_io() thread. If the thread
On Fri, Jun 27, 2014 at 02:44:41PM -0400, Mikulas Patocka wrote:
I suggest - split it to two patches, a minimal patch that fixes the bug by
changing sleeper to completion and the second patch with remaining changes
- so that only the first patch can be backported to stable kernels.
Agreed.
On Sun, Aug 03, 2014 at 12:01:17AM -0400, Pranith Kumar wrote:
Also dm_cblock_t is uint32_t, but atomic_t changes that to int. You
should correct that to atomic64_t to preserve original semantics.
atomic_t used to have only 24 bits of range due to the Sparc
implementation holding a lock in one
by inspecting the code after noticing spurious dirty counts
(scenario B).
Signed-off-by: Anssi Hannula anssi.hann...@iki.fi
Cc: Joe Thornber e...@redhat.com
Cc: sta...@vger.kernel.org
---
Unfortunately it seems there is some other potentially more serious bug
still in there...
After looking
On Fri, Dec 12, 2014 at 09:42:15AM +0900, Akira Hayakawa wrote:
The SSD-caching should be log-structured.
No argument there, and this is why I've supported you with
dm-writeboost over the last couple of years.
However, after looking at the current code, and using it I think it's
a long, long
On Tue, Dec 02, 2014 at 09:00:17AM -0500, Mike Snitzer wrote:
On Tue, Dec 02 2014 at 3:43am -0500,
zhangxiao xiao.zh...@windriver.com wrote:
Hi Experts,
See drivers/md/dm-bufio.c as below:
50 /*
51 * Buffer hash
52 */
53 #define DM_BUFIO_HASH_BITS 20
54
On Mon, Dec 08, 2014 at 06:04:41AM +0900, Akira Hayakawa wrote:
Mike and Alasdair,
I need your ack
Hi Akira,
I just spent some time playing with your latest code. On the positive
side I am seeing some good performance with the fio tests. Which is
great, we know your design should outperform
On Tue, Dec 09, 2014 at 03:12:53PM +, Joe Thornber wrote:
Writeboost is significantly slower than the spindle alone for this
very simple test. I do not understand what is causing the issue.
I started doing the code review and now understand what's going on,
sadly.
You are splitting all
On Wed, Dec 10, 2014 at 08:00:13PM +0900, Akira Hayakawa wrote:
By the way, what environment are you using for those tests?
Those test are on a vm, with a consumer level spindle and SSD behind it.
- Joe
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Wed, Dec 10, 2014 at 08:00:13PM +0900, Akira Hayakawa wrote:
Hi, Joe
Thanks for continuous evaluation.
Some more details:
dd, with block size 512b
raw spindle : 143
writeboost Type 0: 137
writeboost Type 1: 130
dd, with block size 4k
--
On Wed, Dec 10, 2014 at 09:59:12PM +0900, Akira Hayakawa wrote:
Joe,
I appreciate your continuous work.
Is that read or write?
The difference between Type 0 and 1 should only show up in write path.
So is it write test?
Yes, writing across the whole device using 'dd'.
These are the
On Wed, Dec 10, 2014 at 10:31:31PM +0900, Akira Hayakawa wrote:
Joe,
So you copy the bio payload to a different block of ram and then
complete the bio? Or does the rambuf refer to the bio payload
directly?
Good question.
The answer is, copy the data (got by bio_data(bio)) to rambuf
On Sun, Jan 04, 2015 at 10:24:16PM -0500, nick wrote:
Greetings All,
I have a few questions about the function I stated in the message for this
email.
1. What is the issues with the CPU usage for this function?
At the moment it can perform up to NR_QUEUE_LEVELS (16) list_empty()
calls.
On Sat, Feb 21, 2015 at 12:25:53AM +0900, Akira Hayakawa wrote:
Yes.
How big are your log chunks? Presumably they're relatively small (eg,
256k). In which case you can optimise for the common case where you
have enough bios to hand to build your log chunk by just referencing
the bio payloads,
On Fri, Feb 20, 2015 at 05:44:01PM +0900, Akira Hayakawa wrote:
I will wait for ack from dm maintainers.
Are you still copying the contents of every bio to your own memory
buffer before writing it to disk?
- Joe
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Sat, Feb 21, 2015 at 01:06:08AM +0900, Akira Hayakawa wrote:
The size is configurable but typically 512KB (that's the default).
Refer to bio payload sounds really dangerous but it may be possible
in some tricky way. but at the moment I am not sure how the
implementation would be.
Is
On Thu, Jan 28, 2016 at 01:50:19PM +, Andy Whitcroft wrote:
> How would we feel about carrying something like the patch below in
> mainline to allow for such target local ioctls.
You can send a dm message to individual targets. No need for target
specific ioctls.
- Joe
On Sun, Jul 28, 2013 at 11:42:57AM +0900, Akira Hayakawa wrote:
> I wrote an introduction slide which is available in URL below:
> https://github.com/akiradeveloper/dm-lc/blob/develop/what-is-dm-lc.pdf
> access the page and click "view raw".
This is nicely orthogonal to dm-cache.
dm-cache tries
On Wed, May 08, 2013 at 06:05:26PM -0400, Mike Snitzer wrote:
> I'll defer to Joe on this but I think sync_metadata() is pretty heavy to
> be doing every 'dmsetup info'. BTW, with just dm_cache_commit() the
> superblock fields aren't stale; only the on-disk hints are.
Agreed, the hints are v.
On Thu, May 09, 2013 at 01:44:38PM -0700, Darrick J. Wong wrote:
> When userspace queries dmcache for stats info, we should ensure that all the
> metadata gets flushed out of memory to disk. The current code neglects to
> update the disk copy of the hit/miss counters.
Nack, I'm afraid. The
On Thu, May 09, 2013 at 01:47:51PM -0700, Darrick J. Wong wrote:
> Create a new 'flush' message that causes the dmcache to write all of its
> metadata out to disk. This enables us to ensure that the disk reflects
> whatever's in memory without having to tear down the cache device. This helps
>
Hi Darrick,
On Thu, Apr 11, 2013 at 12:22:39AM -0700, Darrick J. Wong wrote:
> Hi all,
>
> Lately I've been having some fun playing with bcache, dmcache, and enhanceio.
I pushed some tweaks to the mq policy today to my thin-dev tree. They
show some improvements to these fio based tests.
In
On Mon, Apr 15, 2013 at 09:55:39AM -0400, Mike Snitzer wrote:
> On Sat, Apr 13 2013 at 3:33pm -0400,
> Mike Snitzer wrote:
>
> > On Sat, Apr 13 2013 at 12:09pm -0400,
> > Joe Thornber wrote:
> >
> > > Hi Darrick,
> > >
> > > On Thu, A
Hi Darrick,
On Fri, Mar 22, 2013 at 01:11:51PM -0700, Darrick J. Wong wrote:
> The new writethrough strategy for dm-cache issues a bio to the origin device,
> remaps the bio to the cache device, and issues the bio to the cache device.
> However, the block layer modifies bi_sector and bi_size, so
On Tue, Jun 11, 2013 at 03:05:07PM +, OS Engineering wrote:
...
> Dm-cache commits on-disk metadata every time a REQ_SYNC or REQ_FUA
> bio is written. If no such requests are made then it commits
> metadata once every second. If power is lost, it may lose some
> recent writes.
Not true
Hi Matias,
This looks really interesting and I'd love to get involved. Do you
have any recommendations for what hardware I should pick up?
- Joe
On Thu, Mar 20, 2014 at 11:32:17PM -0700, Matias Bjørling wrote:
> Hi,
>
> Users that have custom firmware SSDs, may choose to expose their flash
r.
- Joe
Author: Joe Thornber
Date: Fri Jun 27 15:49:29 2014 +0100
[dm-io] Fix a race condition in the wake up code for sync_io
There's a race condition between the atomic_dec_and_test(>count)
in dec_count() and the waking of the sync_io() thread. If the thread
is spur
On Fri, Jun 27, 2014 at 02:44:41PM -0400, Mikulas Patocka wrote:
> I suggest - split it to two patches, a minimal patch that fixes the bug by
> changing sleeper to completion and the second patch with remaining changes
> - so that only the first patch can be backported to stable kernels.
On Tue, May 20, 2014 at 12:53:56PM +0900, na...@elisp.net wrote:
> In era_ctr(), era->md remain NULL until it's set after metadata_open().
> On the other hand, era_destroy() assume era->md is non-NULL and it is
> called by era_ctr() before initializing the value.
Thanks. This change went into my
On Sun, Aug 03, 2014 at 12:01:17AM -0400, Pranith Kumar wrote:
> Also dm_cblock_t is uint32_t, but atomic_t changes that to int. You
> should correct that to atomic64_t to preserve original semantics.
atomic_t used to have only 24 bits of range due to the Sparc
implementation holding a lock in
On Tue, Dec 02, 2014 at 09:00:17AM -0500, Mike Snitzer wrote:
> On Tue, Dec 02 2014 at 3:43am -0500,
> zhangxiao wrote:
>
> > Hi Experts,
> >
> > See drivers/md/dm-bufio.c as below:
> > 50 /*
> > 51 * Buffer hash
> > 52 */
> > 53 #define DM_BUFIO_HASH_BITS 20
> > 54 #define
On Tue, Dec 09, 2014 at 03:12:53PM +, Joe Thornber wrote:
> Writeboost is significantly slower than the spindle alone for this
> very simple test. I do not understand what is causing the issue.
I started doing the code review and now understand what's going on,
sadly.
You are splitti
On Wed, Dec 10, 2014 at 08:00:13PM +0900, Akira Hayakawa wrote:
> By the way, what environment are you using for those tests?
Those test are on a vm, with a consumer level spindle and SSD behind it.
- Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Wed, Dec 10, 2014 at 08:00:13PM +0900, Akira Hayakawa wrote:
> Hi, Joe
>
> Thanks for continuous evaluation.
Some more details:
dd, with block size 512b
raw spindle : 143
writeboost Type 0: 137
writeboost Type 1: 130
dd, with block size 4k
On Wed, Dec 10, 2014 at 09:59:12PM +0900, Akira Hayakawa wrote:
> Joe,
>
> I appreciate your continuous work.
>
> Is that read or write?
> The difference between Type 0 and 1 should only show up in write path.
> So is it write test?
Yes, writing across the whole device using 'dd'.
These are
On Wed, Dec 10, 2014 at 10:31:31PM +0900, Akira Hayakawa wrote:
> Joe,
>
> > So you copy the bio payload to a different block of ram and then
> > complete the bio? Or does the rambuf refer to the bio payload
> > directly?
> Good question.
> The answer is, copy the data (got by bio_data(bio)) to
On Fri, Dec 12, 2014 at 09:42:15AM +0900, Akira Hayakawa wrote:
> The SSD-caching should be log-structured.
No argument there, and this is why I've supported you with
dm-writeboost over the last couple of years.
However, after looking at the current code, and using it I think it's
a long, long
ng clear_dirty() before calling cell_defer().
> Incoming bios for that block will then be detained in the cell and
> released only after clear_dirty() has completed, so the race will not
> occur.
>
> Found by inspecting the code after noticing spurious dirty counts
> (scenario B).
>
On Mon, Dec 08, 2014 at 06:04:41AM +0900, Akira Hayakawa wrote:
> Mike and Alasdair,
> I need your ack
Hi Akira,
I just spent some time playing with your latest code. On the positive
side I am seeing some good performance with the fio tests. Which is
great, we know your design should
On Sun, Jan 04, 2015 at 10:24:16PM -0500, nick wrote:
> Greetings All,
> I have a few questions about the function I stated in the message for this
> email.
> 1. What is the issues with the CPU usage for this function?
At the moment it can perform up to NR_QUEUE_LEVELS (16) list_empty()
calls.
On Fri, Feb 20, 2015 at 05:44:01PM +0900, Akira Hayakawa wrote:
> I will wait for ack from dm maintainers.
Are you still copying the contents of every bio to your own memory
buffer before writing it to disk?
- Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Sat, Feb 21, 2015 at 12:25:53AM +0900, Akira Hayakawa wrote:
> Yes.
How big are your log chunks? Presumably they're relatively small (eg,
256k). In which case you can optimise for the common case where you
have enough bios to hand to build your log chunk by just referencing
the bio payloads,
On Sat, Feb 21, 2015 at 01:06:08AM +0900, Akira Hayakawa wrote:
> The size is configurable but typically 512KB (that's the default).
>
> Refer to bio payload sounds really dangerous but it may be possible
> in some tricky way. but at the moment I am not sure how the
> implementation would be.
>
On Thu, Jan 28, 2016 at 01:50:19PM +, Andy Whitcroft wrote:
> How would we feel about carrying something like the patch below in
> mainline to allow for such target local ioctls.
You can send a dm message to individual targets. No need for target
specific ioctls.
- Joe
On Thu, Sep 26, 2013 at 01:43:25PM +1000, Dave Chinner wrote:
> On Tue, Sep 24, 2013 at 09:20:50PM +0900, Akira Hayakawa wrote:
> > * Deferring ACK for barrier writes
> > Barrier flags such as REQ_FUA and REQ_FLUSH are handled lazily.
> > Immediately handling these bios badly slows down
On Thu, Oct 03, 2013 at 10:27:54PM +0900, Akira Hayakawa wrote:
> > dm-cache doesn't have this problem, if you overwrite the same piece of
> > data again and again, it goes to the cache device.
>
> It is not a bug but should/can be optimized.
>
> Below is the cache hit path for writes.
>
58 matches
Mail list logo
