All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
To: Christoph Hellwig <hch@lst.de>,
	linux-nvdimm@ml01.01.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, x86@kernel.org
Cc: ross.zwisler@linux.intel.com, axboe@kernel.dk, boaz@plexistor.com
Subject: Re: [PATCH 1/3] pmem: Initial version of persistent memory driver
Date: Wed, 8 Apr 2015 13:33:23 -0500	[thread overview]
Message-ID: <201504081833.t38IXN4q003069@wind.enjellic.com> (raw)
In-Reply-To: Christoph Hellwig <hch@lst.de> "[PATCH 1/3] pmem: Initial version of persistent memory driver" (Mar 26,  9:32am)

On Mar 26,  9:32am, Christoph Hellwig wrote:
} Subject: [PATCH 1/3] pmem: Initial version of persistent memory driver

Hi, I hope the week has been going well for everyone.

> From: Ross Zwisler <ross.zwisler@linux.intel.com>
> 
> PMEM is a new driver that presents a reserved range of memory as a
> block device.  This is useful for developing with NV-DIMMs, and
> can be used with volatile memory as a development platform.

We are interested in NV-DIMM's for a variety of reasons so the
discussion on this has been interesting, particularly the 'correct'
method of abstracting access.

We needed a block device representation of memory for a number of
projects we are working on and put the following together:

ftp://ftp.enjellic.com/pub/hpd/hpd_driver-1.1beta.tar.gz

Which has patches for 3.10 and 3.14.

We built HPD on top of the hugepage kernel infrastructure.  In our
opinion, for whatever that is worth, there were a number of advantages
to building this on a page based abstraction.  Not the least of which
was that NUMA awareness just naturally fell out of that model.

While the above patches don't have support for 1GB pages in them that
was also a straight forward exercise.

I don't even pretend to understand all the complexities and mechanics
of the E820/EFI memory mapping issues involved or the various issues
with persistency triggers and such but mapping these through something
like the hugepage infrastructure 'feels' like it would have a number
of longterm advantages with respect to isolating implementations from
the block layer interface.

Have a good remainder of the week.

Greg

}-- End of excerpt from Christoph Hellwig

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"This patch causes a CONFIG_PREEMPT=y, CONFIG_PREEMPT_BKL=y,
 CONFIG_DEBUG_PREEMPT=y kernel on a ppc64 G5 to hang immediately after
 displaying the penguins, but apparently not before having set the
 hardware clock backwards 101 years."

"After having carefully reviewed the above description and having
 decided that these effects were not a part of the patch's design
 intent I have temporarily set it aside, thanks."
                                -- Andrew Morton
                                   linux-kernel

             reply	other threads:[~2015-04-08 19:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-08 18:33 Dr. Greg Wettstein [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-03-26  8:32 another pmem variant V2 Christoph Hellwig
2015-03-26  8:32 ` [PATCH 1/3] pmem: Initial version of persistent memory driver Christoph Hellwig
2015-03-25 16:04 another pmem variant Christoph Hellwig
2015-03-25 16:04 ` [PATCH 1/3] pmem: Initial version of persistent memory driver Christoph Hellwig
2015-03-25 20:19   ` Paul Bolle
2015-03-25 20:26     ` Ross Zwisler
2015-03-26  8:04       ` Christoph Hellwig
2015-03-25 20:21   ` Ross Zwisler
2015-03-26  8:06     ` Christoph Hellwig
2015-05-04 16:43       ` Ross Zwisler
2015-05-04 16:43         ` Ross Zwisler
2015-05-07  7:26         ` Christoph Hellwig
2015-05-07  8:35           ` Boaz Harrosh

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=201504081833.t38IXN4q003069@wind.enjellic.com \
    --to=greg@wind.enjellic.com \
    --cc=axboe@kernel.dk \
    --cc=boaz@plexistor.com \
    --cc=greg@enjellic.com \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@ml01.01.org \
    --cc=ross.zwisler@linux.intel.com \
    --cc=x86@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 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.