s.infradead.org;
>> linux-fsde...@veger.org; linux-kernel@vger.kernel.org
>> Subject: Re: RFC Block Layer Extensions to Support NV-DIMMs
>>
>> On Thu, Sep 26, 2013 at 02:56:17PM +, Zuckerman, Boris wrote:
>>> To work with persistent memory as efficiently as we can wor
nux-fsde...@veger.org; linux-kernel@vger.kernel.org
> Subject: Re: RFC Block Layer Extensions to Support NV-DIMMs
>
> On Thu, Sep 26, 2013 at 02:56:17PM +, Zuckerman, Boris wrote:
> > To work with persistent memory as efficiently as we can work with RAM we
> > need a
&g
On Thu, Sep 26, 2013 at 02:56:17PM +, Zuckerman, Boris wrote:
> To work with persistent memory as efficiently as we can work with RAM we need
> a bit more than "commit". It's reasonable to expect that we get some
> additional support from CPUs that goes beyond mfence and mflush. That may
> i
2013 2:59 AM
> To: rob.gitt...@linux.intel.com
> Cc: linux-p...@lists.infradead.org; linux-fsde...@veger.org; linux-
> ker...@vger.kernel.org
> Subject: Re: RFC Block Layer Extensions to Support NV-DIMMs
>
> Hi Rob,
>
> Rob Gittins, on 09/23/2013 03:51 PM wrote:
> >
Hi Rob,
Rob Gittins, on 09/23/2013 03:51 PM wrote:
> On Fri, 2013-09-06 at 22:12 -0700, Vladislav Bolkhovitin wrote:
>> Rob Gittins, on 09/04/2013 02:54 PM wrote:
>>> Non-volatile DIMMs have started to become available. A NVDIMMs is a
>>> DIMM that does not lose data across power interruptions.
On Fri, 2013-09-06 at 22:12 -0700, Vladislav Bolkhovitin wrote:
> Rob Gittins, on 09/04/2013 02:54 PM wrote:
> > Non-volatile DIMMs have started to become available. A NVDIMMs is a
> > DIMM that does not lose data across power interruptions. Some of the
> > NVDIMMs act like memory, while others a
Rob Gittins, on 09/04/2013 02:54 PM wrote:
> Non-volatile DIMMs have started to become available. A NVDIMMs is a
> DIMM that does not lose data across power interruptions. Some of the
> NVDIMMs act like memory, while others are more like a block device
> on the memory bus. Application uses vary
> Sent: Thursday, September 05, 2013 4:44 PM
> To: Zuckerman, Boris; Jeff Moyer; Matthew Wilcox
> Cc: linux-p...@lists.infradead.org; rob.gitt...@linux.intel.com; linux-
> ker...@vger.kernel.org
> Subject: Re: RFC Block Layer Extensions to Support NV-DIMMs
>
>
> Hi Boris,
>
org] On
>>Behalf Of Jeff
>> Moyer
>> Sent: Thursday, September 05, 2013 1:16 PM
>> To: Matthew Wilcox
>> Cc: linux-p...@lists.infradead.org; rob.gitt...@linux.intel.com; linux-
>> fsde...@veger.org; linux-kernel@vger.kernel.org
>> Subject: Re: RFC Block Layer
ber 05, 2013 1:16 PM
> To: Matthew Wilcox
> Cc: linux-p...@lists.infradead.org; rob.gitt...@linux.intel.com; linux-
> fsde...@veger.org; linux-kernel@vger.kernel.org
> Subject: Re: RFC Block Layer Extensions to Support NV-DIMMs
>
> Matthew Wilcox writes:
>
> > On Th
On Thu, Sep 05, 2013 at 01:15:40PM -0400, Jeff Moyer wrote:
> Matthew Wilcox writes:
>
> > On Thu, Sep 05, 2013 at 08:12:05AM -0400, Jeff Moyer wrote:
> >> If the memory is available to be mapped into the address space of the
> >> kernel or a user process, then I don't see why we should have a bl
Rob Gittins writes:
>> >void (*commitpmem)(struct block_device *bdev, void *addr);
>>
>> Seems like this would benefit from a length argument as well, no?
>
> Yes. Great point. I will add that in.
Rob, taking it a step further, maybe a vectored interface would be more
flexible. Something
Matthew Wilcox writes:
> On Thu, Sep 05, 2013 at 08:12:05AM -0400, Jeff Moyer wrote:
>> If the memory is available to be mapped into the address space of the
>> kernel or a user process, then I don't see why we should have a block
>> device at all. I think it would make more sense to have a diff
Hi Jeff,
Thanks for taking the time to look at this.
On Thu, 2013-09-05 at 08:12 -0400, Jeff Moyer wrote:
> Rob Gittins writes:
>
> > Direct Memory Mappable DIMMs (DMMD) appear in the system address space
> > and are accessed via load and store instructions. These NVDIMMs
> > are part of the s
On Thu, Sep 05, 2013 at 08:12:05AM -0400, Jeff Moyer wrote:
> If the memory is available to be mapped into the address space of the
> kernel or a user process, then I don't see why we should have a block
> device at all. I think it would make more sense to have a different
> driver class for these
Rob Gittins writes:
> Direct Memory Mappable DIMMs (DMMD) appear in the system address space
> and are accessed via load and store instructions. These NVDIMMs
> are part of the system physical address space (SPA) as memory with
> the attribute that data survives a power interruption. As such th
16 matches
Mail list logo
