linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	Christoph Hellwig <hch@lst.de>, Linux MM <linux-mm@kvack.org>,
	dm-devel@redhat.com, Ross Zwisler <ross.zwisler@linux.intel.com>,
	Laura Abbott <labbott@redhat.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [dm-devel] [PATCH] vmalloc: introduce vmap_pfn for persistent memory
Date: Thu, 9 Nov 2017 11:40:24 -0500 (EST)	[thread overview]
Message-ID: <alpine.LRH.2.02.1711091138450.9079@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <CAPcyv4imHXhcd8WgW5ygrKKNiVr0cDZLi2Ue5WDy=_RmqECnvw@mail.gmail.com>



On Wed, 8 Nov 2017, Dan Williams wrote:

> On Wed, Nov 8, 2017 at 12:15 PM, Mikulas Patocka <mpatocka@redhat.com> wrote:
> >
> >
> > On Wed, 8 Nov 2017, Dan Williams wrote:
> >
> >> On Wed, Nov 8, 2017 at 7:35 AM, Christoph Hellwig <hch@infradead.org> wrote:
> >> > On Wed, Nov 08, 2017 at 10:21:38AM -0500, Mikulas Patocka wrote:
> >> >> > And what do you do for an architecture with virtuall indexed caches?
> >> >>
> >> >> Persistent memory is not supported on such architectures - it is only
> >> >> supported on x86-64 and arm64.
> >> >
> >> > For now.  But once support is added your driver will just corrupt data
> >> > unless you have the right API in place.
> >>
> >> I'm also in the process of ripping out page-less dax support. With
> >> pages we can potentially leverage the VIVT-cache support in some
> >> architectures, likely with more supporting infrastructure for
> >> dax_flush().
> >
> > Should I remove all the code for page-less persistent memory from my
> > driver?
> >
> 
> Yes, that would be my recommendation. You can see that filesystem-dax
> is on its way to dropping page-less support in this series:
> 
>    https://lists.01.org/pipermail/linux-nvdimm/2017-October/013125.html

Why do you indend to drop dax for ramdisk? It's perfect for testing.

On x86, persistent memory can be tested with the memmap kernel parameters, 
but on other architectures, ramdisk is the only option for tests.

Mikulas

--
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-11-09 16:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-07 22:03 [PATCH] vmalloc: introduce vmap_pfn for persistent memory Mikulas Patocka
2017-11-08  9:59 ` Christoph Hellwig
2017-11-08 12:33   ` Mikulas Patocka
2017-11-08 15:04     ` Christoph Hellwig
2017-11-08 15:21       ` Mikulas Patocka
2017-11-08 15:35         ` [dm-devel] " Christoph Hellwig
2017-11-08 15:41           ` Dan Williams
2017-11-08 20:15             ` Mikulas Patocka
2017-11-08 20:25               ` Dan Williams
2017-11-09 16:40                 ` Mikulas Patocka [this message]
2017-11-09 16:45                   ` Dan Williams
2017-11-09 17:30                     ` Mikulas Patocka
2017-11-09 17:35                       ` Dan Williams
2017-11-08 17:42           ` Mikulas Patocka
2017-11-08 17:47             ` Christoph Hellwig
2017-11-08 20:26               ` Mikulas Patocka
2017-11-08 21:26                 ` Dan Williams
2017-11-09 16:37                   ` Mikulas Patocka
2017-11-09 16:49                     ` Dan Williams
2017-11-09 18:13                       ` Mikulas Patocka
2017-11-09 18:38                         ` Dan Williams
2017-11-09 18:51                           ` Mikulas Patocka
2017-11-09 18:58                             ` Dan Williams

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=alpine.LRH.2.02.1711091138450.9079@file01.intranet.prod.int.rdu2.redhat.com \
    --to=mpatocka@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=dm-devel@redhat.com \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=labbott@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).