> From: Dan Williams [mailto:dan.j.willi...@intel.com]
> Sent: Wednesday, May 16, 2018 10:49 AM
> On Tue, May 15, 2018 at 7:05 PM, Huaisheng HS1 Ye wrote:
> >> From: Matthew Wilcox [mailto:wi...@infradead.org]
> >> Sent: Wednesday, May 16, 2018 12:20 AM>
> >> > > > > Then there's the problem of re
On Tue, May 15, 2018 at 7:52 PM, Matthew Wilcox wrote:
> On Wed, May 16, 2018 at 02:05:05AM +, Huaisheng HS1 Ye wrote:
>> > From: Matthew Wilcox [mailto:wi...@infradead.org]
>> > Sent: Wednesday, May 16, 2018 12:20 AM>
>> > > > > > Then there's the problem of reconnecting the page cache (which
On Wed, May 16, 2018 at 02:05:05AM +, Huaisheng HS1 Ye wrote:
> > From: Matthew Wilcox [mailto:wi...@infradead.org]
> > Sent: Wednesday, May 16, 2018 12:20 AM>
> > > > > > Then there's the problem of reconnecting the page cache (which is
> > > > > > pointed to by ephemeral data structures like
On Tue, May 15, 2018 at 7:05 PM, Huaisheng HS1 Ye wrote:
>> From: Matthew Wilcox [mailto:wi...@infradead.org]
>> Sent: Wednesday, May 16, 2018 12:20 AM>
>> > > > > Then there's the problem of reconnecting the page cache (which is
>> > > > > pointed to by ephemeral data structures like inodes and d
> From: Matthew Wilcox [mailto:wi...@infradead.org]
> Sent: Wednesday, May 16, 2018 12:20 AM>
> > > > > Then there's the problem of reconnecting the page cache (which is
> > > > > pointed to by ephemeral data structures like inodes and dentries) to
> > > > > the new inodes.
> > > > Yes, it is not
On Tue, May 15, 2018 at 04:07:28PM +, Huaisheng HS1 Ye wrote:
> > From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On Behalf
> > Of Matthew
> > Wilcox
> > No. In the current situation, the user knows that either the entire
> > page was written back from the pagecache or none o
> From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On Behalf Of
> Matthew
> Wilcox
> Sent: Friday, May 11, 2018 12:28 AM
> On Wed, May 09, 2018 at 04:47:54AM +, Huaisheng HS1 Ye wrote:
> > > On Tue, May 08, 2018 at 02:59:40AM +, Huaisheng HS1 Ye wrote:
> > > > Currently
On Wed, May 09, 2018 at 04:47:54AM +, Huaisheng HS1 Ye wrote:
> > On Tue, May 08, 2018 at 02:59:40AM +, Huaisheng HS1 Ye wrote:
> > > Currently in our mind, an ideal use scenario is that, we put all page
> > > caches to
> > > zone_nvm, without any doubt, page cache is an efficient and comm
I have only now noticed that you have posted this few days ago
http://lkml.kernel.org/r/1525704627-30114-1-git-send-email-ye...@lenovo.com
There were some good questions asked there and I have many that are
common yet they are not covered in the cover letter. Please _always_
make sure to answer rev
On Tue 08-05-18 10:30:22, Huaisheng Ye wrote:
> Traditionally, NVDIMMs are treated by mm(memory management) subsystem as
> DEVICE zone, which is a virtual zone and both its start and end of pfn
> are equal to 0, mm wouldn’t manage NVDIMM directly as DRAM, kernel uses
> corresponding drivers, which
>
> On Tue, May 08, 2018 at 02:59:40AM +, Huaisheng HS1 Ye wrote:
> > Currently in our mind, an ideal use scenario is that, we put all page
> > caches to
> > zone_nvm, without any doubt, page cache is an efficient and common cache
> > implement, but it has a disadvantage that all dirty data
On Mon, May 7, 2018 at 7:59 PM, Huaisheng HS1 Ye wrote:
>>
>>Dan Williams writes:
>>
>>> On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox
>>wrote:
On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote:
> Traditionally, NVDIMMs are treated by mm(memory management)
>>subsystem as
>>
On Tue, May 08, 2018 at 02:59:40AM +, Huaisheng HS1 Ye wrote:
> Currently in our mind, an ideal use scenario is that, we put all page caches
> to
> zone_nvm, without any doubt, page cache is an efficient and common cache
> implement, but it has a disadvantage that all dirty data within it woul
>
>Dan Williams writes:
>
>> On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox
>wrote:
>>> On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote:
Traditionally, NVDIMMs are treated by mm(memory management)
>subsystem as
DEVICE zone, which is a virtual zone and both its start and en
>
> On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote:
> > Traditionally, NVDIMMs are treated by mm(memory management)
> subsystem as
> > DEVICE zone, which is a virtual zone and both its start and end of pfn
> > are equal to 0, mm wouldn’t manage NVDIMM directly as DRAM, kernel
> uses
On Mon, May 7, 2018 at 12:18 PM, Matthew Wilcox wrote:
> On Mon, May 07, 2018 at 11:57:10AM -0700, Dan Williams wrote:
>> I think adding yet one more mm-zone is the wrong direction. Instead,
>> what we have been considering is a mechanism to allow a device-dax
>> instance to be given back to the k
On Mon, May 7, 2018 at 12:28 PM, Jeff Moyer wrote:
> Dan Williams writes:
[..]
>>> What's the use case?
>>
>> Use NVDIMMs as System-RAM given their potentially higher capacity than
>> DDR. The expectation in that case is that data is forfeit (not
>> persisted) after a crash. Any persistent use ca
Dan Williams writes:
> On Mon, May 7, 2018 at 12:08 PM, Jeff Moyer wrote:
>> Dan Williams writes:
>>
>>> On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox wrote:
On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote:
> Traditionally, NVDIMMs are treated by mm(memory management) s
On Mon, May 07, 2018 at 11:57:10AM -0700, Dan Williams wrote:
> I think adding yet one more mm-zone is the wrong direction. Instead,
> what we have been considering is a mechanism to allow a device-dax
> instance to be given back to the kernel as a distinct numa node
> managed by the VM. It seems i
On Mon, May 7, 2018 at 12:08 PM, Jeff Moyer wrote:
> Dan Williams writes:
>
>> On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox wrote:
>>> On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote:
Traditionally, NVDIMMs are treated by mm(memory management) subsystem as
DEVICE zone,
Dan Williams writes:
> On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox wrote:
>> On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote:
>>> Traditionally, NVDIMMs are treated by mm(memory management) subsystem as
>>> DEVICE zone, which is a virtual zone and both its start and end of pfn
>
On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox wrote:
> On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote:
>> Traditionally, NVDIMMs are treated by mm(memory management) subsystem as
>> DEVICE zone, which is a virtual zone and both its start and end of pfn
>> are equal to 0, mm wouldn’
On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote:
> Traditionally, NVDIMMs are treated by mm(memory management) subsystem as
> DEVICE zone, which is a virtual zone and both its start and end of pfn
> are equal to 0, mm wouldn’t manage NVDIMM directly as DRAM, kernel uses
> correspondin
23 matches
Mail list logo
