From: Matthew Wilcox <willy@linux.intel.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Matthew Wilcox <willy@linux.intel.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
lttng-dev <lttng-dev@lists.lttng.org>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: Progress on system crash traces with LTTng using DAX and pmem
Date: Mon, 27 Oct 2014 14:48:09 -0400 [thread overview]
Message-ID: <20141027184809.GW11522@wil.cx> (raw)
In-Reply-To: <465653369.1985.1414241485934.JavaMail.zimbra@efficios.com>
On Sat, Oct 25, 2014 at 12:51:25PM +0000, Mathieu Desnoyers wrote:
> A quick follow up on my progress on using DAX and pmem with
> LTTng. I've been able to successfully gather a user-space
> trace into buffers mmap'd into an ext4 filesystem within
> a pmem block device mounted with -o dax to bypass the page
> cache. After a soft reboot, I'm able to mount the partition
> again, and gather the very last data collected in the buffers
> by the applications. I created a "lttng-crash" program that
> extracts data from those buffers and converts the content
> into a readable Common Trace Format trace. So I guess
> you have a use-case for your patchsets on commodity hardware
> right there. :)
Sweet!
> I've been asked by my customers if DAX would work well with
> mtd-ram, which they are using. To you foresee any roadblock
> with this approach ?
Looks like we'd need to add support to mtd-blkdevs.c for DAX. I assume
they're already using one of the block-based ways to expose MTD to
filesystems, rather than jffs2/logfs/ubifs?
I'm thinking we might want to add a flag somewhere in the block_dev / bdi
that indicates whether DAX is supported. Currently we rely on whether
->direct_access is present in the block_device_operations to indicate
that, so we'd have to have two block_dev_operations in mtd-blkdevs,
depending on whether direct access is supported by the underlying
MTD device. Not a show-stopper.
> Please keep me in CC on your next patch versions. I'm willing
> to spend some more time reviewing them if needed. By the way,
> do you guys have a target time-frame/kernel version you aim
> at for getting this work upstream ?
We're trying to get it upstream ASAP. We've been working on it
publically since December last year, and it's getting frustrating that
it's not upstream already. I sent a v12 a few minutes before you sent
this message ... I thought git would add you to the cc's since your
Reviewed-by is on some of the patches.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@linux.intel.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Matthew Wilcox <willy@linux.intel.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
lttng-dev <lttng-dev@lists.lttng.org>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: Progress on system crash traces with LTTng using DAX and pmem
Date: Mon, 27 Oct 2014 14:48:09 -0400 [thread overview]
Message-ID: <20141027184809.GW11522@wil.cx> (raw)
In-Reply-To: <465653369.1985.1414241485934.JavaMail.zimbra@efficios.com>
On Sat, Oct 25, 2014 at 12:51:25PM +0000, Mathieu Desnoyers wrote:
> A quick follow up on my progress on using DAX and pmem with
> LTTng. I've been able to successfully gather a user-space
> trace into buffers mmap'd into an ext4 filesystem within
> a pmem block device mounted with -o dax to bypass the page
> cache. After a soft reboot, I'm able to mount the partition
> again, and gather the very last data collected in the buffers
> by the applications. I created a "lttng-crash" program that
> extracts data from those buffers and converts the content
> into a readable Common Trace Format trace. So I guess
> you have a use-case for your patchsets on commodity hardware
> right there. :)
Sweet!
> I've been asked by my customers if DAX would work well with
> mtd-ram, which they are using. To you foresee any roadblock
> with this approach ?
Looks like we'd need to add support to mtd-blkdevs.c for DAX. I assume
they're already using one of the block-based ways to expose MTD to
filesystems, rather than jffs2/logfs/ubifs?
I'm thinking we might want to add a flag somewhere in the block_dev / bdi
that indicates whether DAX is supported. Currently we rely on whether
->direct_access is present in the block_device_operations to indicate
that, so we'd have to have two block_dev_operations in mtd-blkdevs,
depending on whether direct access is supported by the underlying
MTD device. Not a show-stopper.
> Please keep me in CC on your next patch versions. I'm willing
> to spend some more time reviewing them if needed. By the way,
> do you guys have a target time-frame/kernel version you aim
> at for getting this work upstream ?
We're trying to get it upstream ASAP. We've been working on it
publically since December last year, and it's getting frustrating that
it's not upstream already. I sent a v12 a few minutes before you sent
this message ... I thought git would add you to the cc's since your
Reviewed-by is on some of the patches.
next prev parent reply other threads:[~2014-10-27 18:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1254279794.1957.1414240389301.JavaMail.zimbra@efficios.com>
2014-10-25 12:51 ` Progress on system crash traces with LTTng using DAX and pmem Mathieu Desnoyers
2014-10-25 12:51 ` Mathieu Desnoyers
2014-10-27 18:48 ` Matthew Wilcox [this message]
2014-10-27 18:48 ` Matthew Wilcox
2014-10-30 15:01 ` Mathieu Desnoyers
2014-10-30 15:01 ` Mathieu Desnoyers
2015-01-25 14:55 ` Mathieu Desnoyers
2015-01-25 14:55 ` Mathieu Desnoyers
2014-10-28 10:54 ` Kirill A. Shutemov
2014-10-28 10:54 ` Kirill A. Shutemov
2014-10-30 15:11 ` Mathieu Desnoyers
2014-10-30 15:11 ` Mathieu Desnoyers
2014-12-13 11:48 ` Matt Fleming
2014-12-13 11:48 ` Matt Fleming
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=20141027184809.GW11522@wil.cx \
--to=willy@linux.intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lttng-dev@lists.lttng.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=ross.zwisler@linux.intel.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.