All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viacheslav Dubeyko <slava@dubeyko.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-nvdimm@ml01.01.org, linux-block@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [LSF/MM TOPIC] Future direction of DAX
Date: Sun, 15 Jan 2017 16:19:51 -0800	[thread overview]
Message-ID: <1484525991.27533.31.camel@dubeyko.com> (raw)
In-Reply-To: <20170114082621.GC10498@birch.djwong.org>

On Sat, 2017-01-14 at 00:26 -0800, Darrick J. Wong wrote:

<skipped>

> Some day we'll start designing a pmem-native fs, I guess. :P

There are research efforts in this direction already ([1]-[15]). The
latest one is NOVA, as far as I can see. But, frankly speaking, I
believe that we need in new hardware paradigm/architecture and new OS
paradigm for the next generation of NVM memory. The DAX is
simple palliative, temporary solution. But, from my point of view,
pmem-native fs is also not good direction because, anyway, memory
subsystem will be affected significantly. And, finally, evolution of
memory subsystem will reveal something completely different that we can
imagine right now.

Thanks,
Vyacheslav Dubeyko. 

[1] http://pages.cs.wisc.edu/~swift/papers/eurosys14-aerie.pdf
[2] https://www.researchgate.net/publication/282792714_A_User-Level_File_System_for_Fast_Storage_Devices
[3] https://people.eecs.berkeley.edu/~dcoetzee/publications/Better%20IO%20Through%20Byte-Addressable,%20Persistent%20Memory.pdf
[4] https://www.computer.org/csdl/proceedings/msst/2013/0217/00/06558440.pdf
[5] https://users.soe.ucsc.edu/~scott/papers/MASCOTS04b.pdf
[6] http://ieeexplore.ieee.org/document/4142472/
[7] https://cseweb.ucsd.edu/~swanson/papers/FAST2016NOVA.pdf
[8] http://cesg.tamu.edu/wp-content/uploads/2012/02/MSST13.pdf
[9] http://ieeexplore.ieee.org/document/5487498/
[10] https://pdfs.semanticscholar.org/544c/1ddf24b90c3dfba7b1934049911b869c99b4.pdf
[11] http://pramfs.sourceforge.net/tech.html
[12] https://pdfs.semanticscholar.org/2981/b5abcbe1023b9f3cd962b0be7ef8bd45acfd.pdf
[13] http://ieeexplore.ieee.org/document/6232378/
[14] http://ieeexplore.ieee.org/document/7304365/
[15] http://ieeexplore.ieee.org/document/6272446/

--
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: Viacheslav Dubeyko <slava@dubeyko.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-nvdimm@ml01.01.org, linux-block@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [LSF/MM TOPIC] Future direction of DAX
Date: Sun, 15 Jan 2017 16:19:51 -0800	[thread overview]
Message-ID: <1484525991.27533.31.camel@dubeyko.com> (raw)
In-Reply-To: <20170114082621.GC10498@birch.djwong.org>

On Sat, 2017-01-14 at 00:26 -0800, Darrick J. Wong wrote:

<skipped>

> Some day we'll start designing a pmem-native fs, I guess. :P

There are research efforts in this direction already ([1]-[15]). The
latest one is NOVA, as far as I can see. But, frankly speaking, I
believe that we need in new hardware paradigm/architecture and new OS
paradigm for the next generation of NVM memory. The DAX is
simple palliative, temporary solution. But, from my point of view,
pmem-native fs is also not good direction because, anyway, memory
subsystem will be affected significantly. And, finally, evolution of
memory subsystem will reveal something completely different that we can
imagine right now.

Thanks,
Vyacheslav Dubeyko. 

[1] http://pages.cs.wisc.edu/~swift/papers/eurosys14-aerie.pdf
[2] https://www.researchgate.net/publication/282792714_A_User-Level_File_System_for_Fast_Storage_Devices
[3] https://people.eecs.berkeley.edu/~dcoetzee/publications/Better%20IO%20Through%20Byte-Addressable,%20Persistent%20Memory.pdf
[4] https://www.computer.org/csdl/proceedings/msst/2013/0217/00/06558440.pdf
[5] https://users.soe.ucsc.edu/~scott/papers/MASCOTS04b.pdf
[6] http://ieeexplore.ieee.org/document/4142472/
[7] https://cseweb.ucsd.edu/~swanson/papers/FAST2016NOVA.pdf
[8] http://cesg.tamu.edu/wp-content/uploads/2012/02/MSST13.pdf
[9] http://ieeexplore.ieee.org/document/5487498/
[10] https://pdfs.semanticscholar.org/544c/1ddf24b90c3dfba7b1934049911b869c99b4.pdf
[11] http://pramfs.sourceforge.net/tech.html
[12] https://pdfs.semanticscholar.org/2981/b5abcbe1023b9f3cd962b0be7ef8bd45acfd.pdf
[13] http://ieeexplore.ieee.org/document/6232378/
[14] http://ieeexplore.ieee.org/document/7304365/
[15] http://ieeexplore.ieee.org/document/6272446/


WARNING: multiple messages have this Message-ID (diff)
From: Viacheslav Dubeyko <slava@dubeyko.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-nvdimm@ml01.01.org, linux-block@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [LSF/MM TOPIC] Future direction of DAX
Date: Sun, 15 Jan 2017 16:19:51 -0800	[thread overview]
Message-ID: <1484525991.27533.31.camel@dubeyko.com> (raw)
In-Reply-To: <20170114082621.GC10498@birch.djwong.org>

On Sat, 2017-01-14 at 00:26 -0800, Darrick J. Wong wrote:

<skipped>

> Some day we'll start designing a pmem-native fs, I guess. :P

There are research efforts in this direction already ([1]-[15]). The
latest one is NOVA, as far as I can see. But, frankly speaking, I
believe that we need in new hardware paradigm/architecture and new OS
paradigm for the next generation of NVM memory. The DAX is
simpleA palliative, temporary solution. But, from my point of view,
pmem-native fs is also not good direction because, anyway, memory
subsystem will be affected significantly. And, finally, evolution of
memory subsystem will reveal something completely different that we can
imagine right now.

Thanks,
Vyacheslav Dubeyko.A 

[1]A http://pages.cs.wisc.edu/~swift/papers/eurosys14-aerie.pdf
[2]A https://www.researchgate.net/publication/282792714_A_User-Level_File_System_for_Fast_Storage_Devices
[3] https://people.eecs.berkeley.edu/~dcoetzee/publications/Better%20IO%20Through%20Byte-Addressable,%20Persistent%20Memory.pdf
[4] https://www.computer.org/csdl/proceedings/msst/2013/0217/00/06558440.pdf
[5] https://users.soe.ucsc.edu/~scott/papers/MASCOTS04b.pdf
[6] http://ieeexplore.ieee.org/document/4142472/
[7] https://cseweb.ucsd.edu/~swanson/papers/FAST2016NOVA.pdf
[8] http://cesg.tamu.edu/wp-content/uploads/2012/02/MSST13.pdf
[9] http://ieeexplore.ieee.org/document/5487498/
[10] https://pdfs.semanticscholar.org/544c/1ddf24b90c3dfba7b1934049911b869c99b4.pdf
[11] http://pramfs.sourceforge.net/tech.html
[12] https://pdfs.semanticscholar.org/2981/b5abcbe1023b9f3cd962b0be7ef8bd45acfd.pdf
[13] http://ieeexplore.ieee.org/document/6232378/
[14] http://ieeexplore.ieee.org/document/7304365/
[15] http://ieeexplore.ieee.org/document/6272446/

--
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>

  reply	other threads:[~2017-01-16  0:19 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-14  0:20 [LSF/MM TOPIC] Future direction of DAX Ross Zwisler
2017-01-14  0:20 ` Ross Zwisler
2017-01-14  0:20 ` Ross Zwisler
     [not found] ` <20170114002008.GA25379-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-01-14  8:26   ` Darrick J. Wong
2017-01-14  8:26     ` Darrick J. Wong
2017-01-14  8:26     ` Darrick J. Wong
2017-01-16  0:19     ` Viacheslav Dubeyko [this message]
2017-01-16  0:19       ` Viacheslav Dubeyko
2017-01-16  0:19       ` Viacheslav Dubeyko
2017-01-16 20:00     ` Jeff Moyer
2017-01-16 20:00       ` Jeff Moyer
2017-01-17  1:50       ` Darrick J. Wong
2017-01-17  1:50         ` Darrick J. Wong
2017-01-17  2:42         ` Dan Williams
2017-01-17  2:42           ` Dan Williams
     [not found]         ` <20170117015033.GD10498-PTl6brltDGh4DFYR7WNSRA@public.gmane.org>
2017-01-17  7:57           ` Christoph Hellwig
2017-01-17  7:57             ` Christoph Hellwig
2017-01-17  7:57             ` Christoph Hellwig
2017-01-17 14:54             ` Jeff Moyer
2017-01-17 14:54               ` Jeff Moyer
     [not found]               ` <x49mvep4tzw.fsf-RRHT56Q3PSP4kTEheFKJxxDDeQx5vsVwAInAS/Ez/D0@public.gmane.org>
2017-01-17 15:06                 ` Christoph Hellwig
2017-01-17 15:06                   ` Christoph Hellwig
2017-01-17 15:06                   ` Christoph Hellwig
     [not found]                   ` <20170117150638.GA3747-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2017-01-17 16:07                     ` Jeff Moyer
2017-01-17 16:07                       ` Jeff Moyer
2017-01-17 16:07                       ` Jeff Moyer
2017-01-17 15:59 ` [Lsf-pc] " Jan Kara
2017-01-17 15:59   ` Jan Kara
2017-01-17 15:59   ` Jan Kara
2017-01-17 16:56   ` Dan Williams
2017-01-17 16:56     ` Dan Williams
2017-01-17 16:56     ` Dan Williams
2017-01-18  0:03   ` Kani, Toshimitsu
2017-01-18  0:03     ` Kani, Toshimitsu
2017-01-18  0:03     ` Kani, Toshimitsu
2017-01-18  5:25 ` willy
2017-01-18  5:25   ` willy
2017-01-18  5:25   ` willy
2017-01-18  6:01   ` Dan Williams
2017-01-18  6:01     ` Dan Williams
2017-01-18  6:01     ` Dan Williams
2017-01-18  6:07     ` willy
2017-01-18  6:07       ` willy
2017-01-18  6:07       ` willy
2017-01-18  6:25       ` Dan Williams
2017-01-18  6:25         ` Dan Williams
2017-01-18  6:25         ` Dan Williams
2017-01-18 17:22   ` Ross Zwisler
2017-01-18 17:22     ` Ross Zwisler
2017-01-18 17:22     ` Ross Zwisler

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=1484525991.27533.31.camel@dubeyko.com \
    --to=slava@dubeyko.com \
    --cc=darrick.wong@oracle.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@ml01.01.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --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.