On 05/27/2015 11:11 AM, Christoph Hellwig wrote:
> On Wed, May 27, 2015 at 11:10:21AM +0300, Boaz Harrosh wrote:
>> Hu funny I just looked and I see with ./check auto I get
>> generic/018 1s ... [not run] defragmentation not supported for fstype "m1fs"
>> generic/020 0s ... 0s
>>
>> 019 is not even
On Wed, May 27, 2015 at 11:10:21AM +0300, Boaz Harrosh wrote:
> Hu funny I just looked and I see with ./check auto I get
> generic/018 1s ... [not run] defragmentation not supported for fstype "m1fs"
> generic/020 0s ... 0s
>
> 019 is not even printing a skip. But if I run it directly I get:
> gen
On 05/26/2015 10:31 PM, Matthew Wilcox wrote:
> On Tue, May 26, 2015 at 11:41:41AM +0300, Boaz Harrosh wrote:
>> I would please like to help. What is the breakage you
>> see with DAX.
>>
>> I'm routinely testing with DAX so it is a surprise,
>> Though I'm testing with my version with pages and
>> _
* Matthew Wilcox wrote:
> On Mon, Apr 13, 2015 at 11:33:09AM +0200, Ingo Molnar wrote:
> > Please pull the latest x86-pmem-for-linus git tree from:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> > x86-pmem-for-linus
> >
> ># HEAD: 4c1eaa2344fb26bb5e936fb4d8ee307343
On Tue, May 26, 2015 at 11:41:41AM +0300, Boaz Harrosh wrote:
> I would please like to help. What is the breakage you
> see with DAX.
>
> I'm routinely testing with DAX so it is a surprise,
> Though I'm testing with my version with pages and
> __copy_from_user_nocache, and so on.
> Or I might have
On 05/25/2015 09:16 PM, Matthew Wilcox wrote:
<>
>
> Ingo, this sucks. You collapsed all of the separate patches into a
> single "add new driver" patch, which makes it impossible to bisect which
> of the recent changes broke xfstests. Please don't do this again.
>
Matthew hi
Below is a splito
* Matthew Wilcox wrote:
> On Mon, Apr 13, 2015 at 11:33:09AM +0200, Ingo Molnar wrote:
> > Please pull the latest x86-pmem-for-linus git tree from:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> > x86-pmem-for-linus
> >
> ># HEAD: 4c1eaa2344fb26bb5e936fb4d8ee307343
On Mon, Apr 13, 2015 at 11:33:09AM +0200, Ingo Molnar wrote:
> Please pull the latest x86-pmem-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> x86-pmem-for-linus
>
># HEAD: 4c1eaa2344fb26bb5e936fb4d8ee307343ea0089 drivers/block/pmem: Fix
> 32-bit
On Fri, Apr 17, 2015 at 2:38 AM, Christoph Hellwig wrote:
> So we'be been busy discussing future steps in this thread for a few days,
> but it seems like Linus doesn't like the pull request. Linus, can you
> say what you don't like here?
I basically don't do pulls that generate a lot of discussi
So we'be been busy discussing future steps in this thread for a few days,
but it seems like Linus doesn't like the pull request. Linus, can you
say what you don't like here?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel
On Wed, Apr 15, 2015 at 1:45 AM, Ingo Molnar wrote:
>
> * Dan Williams wrote:
>
>> > None of this gives me warm fuzzy feelings...
>> >
>> > ... has anyone explored the possibility of putting 'struct page'
>> > into the pmem device itself, essentially using it as metadata?
>>
>> Yes, the impetus f
* Dan Williams wrote:
> > None of this gives me warm fuzzy feelings...
> >
> > ... has anyone explored the possibility of putting 'struct page'
> > into the pmem device itself, essentially using it as metadata?
>
> Yes, the impetus for proposing the pfn conversion of the block layer
> was the
* Elliott, Robert (Server Storage) wrote:
> > -Original Message-
> > From: Linux-nvdimm [mailto:linux-nvdimm-boun...@lists.01.org] On Behalf
> > Of Ingo Molnar
> > Sent: Tuesday, April 14, 2015 7:42 AM
> > To: Christoph Hellwig
> > Subject: Re: [Linu
> -Original Message-
> From: Dan Williams [mailto:dan.j.willi...@intel.com]
> Sent: Tuesday, April 14, 2015 11:34 AM
> To: Elliott, Robert (Server Storage)
> > ...
> >> Since it's directly mapped it should just work for most things if it's
> >> at least write-through cached (UC would be a
ellwig
>> Subject: Re: [Linux-nvdimm] [GIT PULL] PMEM driver for v4.1
>>
>>
> ...
>> Since it's directly mapped it should just work for most things if it's
>> at least write-through cached (UC would be a horror), and it would
>> also solve all the size
On Tue, Apr 14, 2015 at 5:41 AM, Ingo Molnar wrote:
> 2) pmem devices as 'memory':
>
> Battery backed and similar solutions of nv-dram, these are probably a
> lot smaller (for cost reasons) and are also a lot more RAM-alike, so
> the 'struct page' allocation in main RAM makes sense and possibly
>
> -Original Message-
> From: Linux-nvdimm [mailto:linux-nvdimm-boun...@lists.01.org] On Behalf
> Of Ingo Molnar
> Sent: Tuesday, April 14, 2015 7:42 AM
> To: Christoph Hellwig
> Subject: Re: [Linux-nvdimm] [GIT PULL] PMEM driver for v4.1
>
>
...
> Since it&
On 04/14/2015 03:41 PM, Ingo Molnar wrote:
>
> * Christoph Hellwig wrote:
>
>> On Mon, Apr 13, 2015 at 12:45:32PM +0200, Ingo Molnar wrote:
>>> Btw., what's the future design plan here? Enable struct page backing,
>>> or provide special codepaths for all DAX uses like the special pte
>>> based
* Christoph Hellwig wrote:
> On Mon, Apr 13, 2015 at 12:45:32PM +0200, Ingo Molnar wrote:
> > Btw., what's the future design plan here? Enable struct page backing,
> > or provide special codepaths for all DAX uses like the special pte
> > based approach for mmap()s?
>
> There are a couple app
On 04/13/2015 08:19 PM, Christoph Hellwig wrote:
> On Mon, Apr 13, 2015 at 02:11:56PM +0300, Yigal Korman wrote:
>> mlock()
>
> DAX files always are in-memory so this just sounds like an oversight.
> method.
Yes mlock on DAX can just return true, but mlock implies MAP_POPULATE.
Which means "I wo
On Mon, Apr 13, 2015 at 12:45:32PM +0200, Ingo Molnar wrote:
> Btw., what's the future design plan here? Enable struct page backing,
> or provide special codepaths for all DAX uses like the special pte
> based approach for mmap()s?
There are a couple approaches proposed, but we don't have consen
On Mon, Apr 13, 2015 at 02:35:35PM +0200, Ingo Molnar wrote:
> How does splice work with DAX files?
By falling back to default_file_splice_read/default_file_splice_write
which doesn't use the iter ops, but instead requires a copy in the
splice code. But given that the actual underlying reads and
On Mon, Apr 13, 2015 at 02:11:56PM +0300, Yigal Korman wrote:
> mlock()
DAX files always are in-memory so this just sounds like an oversight.
method.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info
On 04/13/2015 03:35 PM, Ingo Molnar wrote:
>
<>
>
> How does splice work with DAX files? AFAICS vmsplice() won't work, as
> it uses get_user_pages(), which needs struct page backing. Also, how
> will f_op->sendpage() work? That too needs page backing.
>
I'm not sure about f_op->sendpage(). I
* Boaz Harrosh wrote:
> On 04/13/2015 01:45 PM, Ingo Molnar wrote:
> >
> > * Christoph Hellwig wrote:
> >
> >> On Mon, Apr 13, 2015 at 11:33:09AM +0200, Ingo Molnar wrote:
> >>> Limitations: this is a regular block device, and since the pmem areas
> >>> are not struct page backed, they are i
On 04/13/2015 01:45 PM, Ingo Molnar wrote:
>
> * Christoph Hellwig wrote:
>
>> On Mon, Apr 13, 2015 at 11:33:09AM +0200, Ingo Molnar wrote:
>>> Limitations: this is a regular block device, and since the pmem areas
>>> are not struct page backed, they are invisible to the rest of the
>>> system
On Mon, Apr 13, 2015 at 1:45 PM, Ingo Molnar wrote:
>
> * Christoph Hellwig wrote:
>
>> On Mon, Apr 13, 2015 at 11:33:09AM +0200, Ingo Molnar wrote:
>> > Limitations: this is a regular block device, and since the pmem areas
>> > are not struct page backed, they are invisible to the rest of the
>>
* Christoph Hellwig wrote:
> On Mon, Apr 13, 2015 at 11:33:09AM +0200, Ingo Molnar wrote:
> > Limitations: this is a regular block device, and since the pmem areas
> > are not struct page backed, they are invisible to the rest of the
> > system (other than the block IO device), so direct IO to
On Mon, Apr 13, 2015 at 11:33:09AM +0200, Ingo Molnar wrote:
> Limitations: this is a regular block device, and since the pmem areas
> are not struct page backed, they are invisible to the rest of the
> system (other than the block IO device), so direct IO to/from pmem
> areas, direct mmap() or
Linus,
Please pull the latest x86-pmem-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-pmem-for-linus
# HEAD: 4c1eaa2344fb26bb5e936fb4d8ee307343ea0089 drivers/block/pmem: Fix
32-bit build warning in pmem_alloc()
This is the initial support for the p
30 matches
Mail list logo
