On Mon, Sep 10, 2018 at 4:44 PM, Alexander Duyck
wrote:
> From: Alexander Duyck
>
> This patch is based off of the pci_call_probe function used to initialize
> PCI devices. The general idea here is to move the probe call to a location
> that is local to the memory being initialized. By doing this
On Tue, Sep 11, 2018 at 5:51 PM, Alexander Duyck
wrote:
> On Tue, Sep 11, 2018 at 3:35 PM Dan Williams wrote:
>>
>> On Mon, Sep 10, 2018 at 4:43 PM, Alexander Duyck
>> wrote:
>> >
>> > From: Alexander Duyck
>> >
>> > The ZONE_DEVICE pages were being initialized in two locations. One was with
>>
On Tue, Sep 11, 2018 at 3:35 PM Dan Williams wrote:
>
> On Mon, Sep 10, 2018 at 4:43 PM, Alexander Duyck
> wrote:
> >
> > From: Alexander Duyck
> >
> > The ZONE_DEVICE pages were being initialized in two locations. One was with
> > the memory_hotplug lock held and another was outside of that loc
On Mon, Sep 10, 2018 at 4:43 PM, Alexander Duyck
wrote:
>
> From: Alexander Duyck
>
> The ZONE_DEVICE pages were being initialized in two locations. One was with
> the memory_hotplug lock held and another was outside of that lock. The
> problem with this is that it was nearly doubling the memory
On Tue, Sep 11, 2018 at 1:01 PM, Alexander Duyck
wrote:
> On Tue, Sep 11, 2018 at 9:50 AM Dan Williams wrote:
>>
>> On Mon, Sep 10, 2018 at 4:43 PM, Alexander Duyck
>> wrote:
>> > From: Alexander Duyck
>> >
>> > On systems with a large amount of memory it can take a significant amount
>> > of t
On Tue, Sep 11, 2018 at 9:50 AM Dan Williams wrote:
>
> On Mon, Sep 10, 2018 at 4:43 PM, Alexander Duyck
> wrote:
> > From: Alexander Duyck
> >
> > On systems with a large amount of memory it can take a significant amount
> > of time to initialize all of the page structs with the PAGE_POISON_PAT
On Tue, 2018-09-11 at 11:15 -0700, Dan Williams wrote:
> On Tue, Sep 11, 2018 at 8:42 AM, Toshi Kani wrote:
> > Sync syscall to an existing DAX file needs to flush processor cache,
> > but it does not currently. This is because 'ext4_da_aops' is set to
> > address_space_operations of existing DAX
On 9/11/18 12:28 PM, Theodore Y. Ts'o wrote:
> On Tue, Sep 11, 2018 at 05:20:24PM +0200, Jan Kara wrote:
>>> Hum, it seems Ted never picked this patch up. I guess I'll gather the two
>>> fixes you pointed out and resend them to Ted.
>>
>> Actually only one patch when looking into it now.
>
> I bel
On Tue, Sep 11, 2018 at 8:42 AM, Toshi Kani wrote:
> Sync syscall to an existing DAX file needs to flush processor cache,
> but it does not currently. This is because 'ext4_da_aops' is set to
> address_space_operations of existing DAX files, instead of 'ext4_dax_aops',
> since S_DAX flag is set a
On Tue, 2018-09-11 at 10:59 -0700, Dan Williams wrote:
> On Tue, Sep 11, 2018 at 8:42 AM, Toshi Kani wrote:
> > Ext4 mount path calls ext4_iget() to obtain the journal inode. This
> > inode does not support DAX, and 'ext4_da_aops' needs to be set. It
> > currently works for the DAX mount case be
On Tue, Sep 11, 2018 at 8:42 AM, Toshi Kani wrote:
> Ext4 mount path calls ext4_iget() to obtain the journal inode. This
> inode does not support DAX, and 'ext4_da_aops' needs to be set. It
> currently works for the DAX mount case because ext4_iget() always set
> 'ext4_da_aops' to any regular fi
On Tue, Sep 11, 2018 at 05:20:24PM +0200, Jan Kara wrote:
> > Hum, it seems Ted never picked this patch up. I guess I'll gather the two
> > fixes you pointed out and resend them to Ted.
>
> Actually only one patch when looking into it now.
I believe both are in the ext4 git tree.
On Mon, Sep 10, 2018 at 4:43 PM, Alexander Duyck
wrote:
> From: Alexander Duyck
>
> On systems with a large amount of memory it can take a significant amount
> of time to initialize all of the page structs with the PAGE_POISON_PATTERN
> value. I have seen it take over 2 minutes to initialize a sy
On Tue, 2018-09-11 at 17:27 +0200, Jan Kara wrote:
> On Mon 10-09-18 17:58:10, Elliott, Robert (Persistent Memory) wrote:
> >
> >
> > > -Original Message-
> > > From: Linux-nvdimm [mailto:linux-nvdimm-boun...@lists.01.org] On Behalf
> > > Of Kani, Toshi
> > > Sent: Monday, September 10,
Ext4 mount path calls ext4_iget() to obtain the journal inode. This
inode does not support DAX, and 'ext4_da_aops' needs to be set. It
currently works for the DAX mount case because ext4_iget() always set
'ext4_da_aops' to any regular files.
ext4_fill_super
ext4_load_journal
ext4_get
Sync syscall to an existing DAX file needs to flush processor cache,
but it does not currently. This is because 'ext4_da_aops' is set to
address_space_operations of existing DAX files, instead of 'ext4_dax_aops',
since S_DAX flag is set after ext4_set_aops() in the open path.
New file
---
This patchset fixes an issue that sync syscall to an existing DAX file
does not flush processor cache.
Patch 1/2 adds a check to skip the journal inode. It's a bit awkward,
but I could not find a beter way to get the journal inode.
Patch 2/2 fixes the issue by moving up ext4_set_inode_flags() bef
On Mon 10-09-18 17:58:10, Elliott, Robert (Persistent Memory) wrote:
>
>
> > -Original Message-
> > From: Linux-nvdimm [mailto:linux-nvdimm-boun...@lists.01.org] On Behalf Of
> > Kani, Toshi
> > Sent: Monday, September 10, 2018 9:52 AM
> > To: j...@suse.cz
> > Cc: linux-fsde...@vger.kern
On Mon 10-09-18 11:23:56, Eric Sandeen wrote:
> On 8/8/18 12:25 PM, Dave Jiang wrote:
> > From: Ross Zwisler
> >
> > If the refcount of a page is lowered between the time that it is returned
> > by dax_busy_page() and when the refcount is again checked in
> > ext4_break_layouts() => ___wait_var_e
On Tue 11-09-18 17:14:21, Jan Kara wrote:
> On Mon 10-09-18 17:18:49, Eric Sandeen wrote:
> > On 8/7/18 3:45 AM, Jan Kara wrote:
> > >
> > > OK, this is a good catch and the patch looks good. You can add:
> > >
> > > Reviewed-by: Jan Kara
> > >
> > > Also please post this fix officially to Ted
On Mon 10-09-18 17:18:49, Eric Sandeen wrote:
> On 8/7/18 3:45 AM, Jan Kara wrote:
> > On Fri 27-07-18 10:28:51, Ross Zwisler wrote:
> >> + fsdevel and the xfs list.
> >>
> >> On Wed, Jul 25, 2018 at 4:28 PM Ross Zwisler
> >> wrote:
> >>> On Wed, Jul 11, 2018 at 10:17:41AM +0200, Jan Kara wrote:
>
> -Original Message-
> From: Dan Williams
> Sent: Tuesday, September 11, 2018 8:51 AM
> To: Ocean He
> Cc: zwis...@kernel.org; Vishal L Verma ; Dave Jiang
> ; linux-nvdimm ; Linux
> Kernel Mailing List ; Ocean HY1 He
>
> Subject: [External] Re: [PATCH 0/3] libnvdimm: reset seeds for n
From: Ocean He
When namespace creation failure occurs, the consumed namespace (seed or 0th
idle) and pfn/dax seed would block next namespace creation. A recovery is
needed to handle this type failure.
A symptom example (section size is 128MB) based on kernel 4.19-rc2 and
ndctl v62:
# ndc
://github.com/0day-ci/linux/commits/Alexander-Duyck/Address-issues-slowing-persistent-memory-initialization/20180911-144536
config: openrisc-or1ksim_defconfig (attached as .config)
compiler: or1k-linux-gcc (GCC) 6.0.0 20160327 (experimental)
reproduce:
wget
https://raw.githubusercontent.com/intel
:
https://github.com/0day-ci/linux/commits/Alexander-Duyck/Address-issues-slowing-persistent-memory-initialization/20180911-144536
config: x86_64-randconfig-x009-201836 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
On Mon, Sep 10, 2018 at 12:11:01PM -0600, Logan Gunthorpe wrote:
> > I just saw you added that "helper" in your tree. Please don't, it is
> > a negative value add as it doesn't help anything with the checking.
>
> Alright, so what's the consensus then? Just have a check in
> nvmet_bdev_execute_rw
26 matches
Mail list logo
