This patch got caught in the crossfire and didn't make it into 4.18
as planned. Can it make 4.19 please?
>8
Use my_zero_pfn instead of ZERO_PAGE, and pass the vaddr to it so it
works on MIPS and s390.
Signed-off-by: Matthew Wilcox
Reviewed-by: Ross Zwisler
---
fs/da
On Thu, Sep 27, 2018 at 01:23:32PM +0200, Jan Kara wrote:
> When dax_lock_mapping_entry() has to sleep to obtain entry lock, it will
> fail to unlock mapping->i_pages spinlock and thus immediately deadlock
> against itself when retrying to grab the entry lock again. Fix the
> problem by unlocking m
On Thu, Oct 04, 2018 at 06:57:52PM -0700, Dan Williams wrote:
> On Thu, Oct 4, 2018 at 9:27 AM Jan Kara wrote:
> >
> > On Thu 27-09-18 11:22:22, Dan Williams wrote:
> > > On Thu, Sep 27, 2018 at 6:41 AM Jan Kara wrote:
> > > >
> > > > On Thu 27-09
On Tue, Nov 06, 2018 at 03:44:47AM +, Williams, Dan J wrote:
> Hi Willy,
>
> I'm seeing the following warning with v4.20-rc1 and the "dax.sh" test
> from the ndctl repository:
I'll try to run this myself later today.
> I tried to get this test going on -next before the merge window, but
> -n
On Wed, Nov 07, 2018 at 06:01:19AM +, Williams, Dan J wrote:
> On Tue, 2018-11-06 at 06:48 -0800, Matthew Wilcox wrote:
> > On Tue, Nov 06, 2018 at 03:44:47AM +, Williams, Dan J wrote:
> > > Hi Willy,
> > >
> > > I'm seeing the following warning w
On Sat, Nov 10, 2018 at 09:08:10AM -0800, Dan Williams wrote:
> On Sat, Nov 10, 2018 at 12:29 AM Matthew Wilcox wrote:
> > On Wed, Nov 07, 2018 at 06:01:19AM +, Williams, Dan J wrote:
> > > On Tue, 2018-11-06 at 06:48 -0800, Matthew Wilcox wrote:
> > > > On T
--
>
> >From 25bbe21bf427a81b8e3ccd480ea0e1d940256156 Mon Sep 17 00:00:00 2001
> From: Matthew Wilcox
> Date: Fri, 16 Nov 2018 15:50:02 -0500
> Subject: [PATCH] dax: Avoid losing wakeup in dax_lock_mapping_entry
>
> After calling get_unlocked_entry(), you have to
On Mon, Nov 26, 2018 at 04:22:23AM -0800, Matthew Wilcox wrote:
> On Mon, Nov 26, 2018 at 11:40:20AM +0100, gre...@linuxfoundation.org wrote:
> >
> > The patch below does not apply to the 4.19-stable tree.
> > If someone wants it applied there, or to any other stable or lo
I noticed this path while I was doing the 4.19 backport of
dax: Avoid losing wakeup in dax_lock_mapping_entry
xa_unlock_irq(&mapping->i_pages);
revalidate = wait_fn();
finish_wait(wq, &ewait.wait);
xa_lock_irq(&mapping->i_pages);
I
On Mon, Nov 26, 2018 at 12:36:26PM -0800, Dan Williams wrote:
> On Mon, Nov 26, 2018 at 9:11 AM Jan Kara wrote:
> > The code looks good. Maybe can we call this wait_entry_unlocked() to stress
> > that entry is not really usable after this function returns? And comment
> > before the function that
ernel.org
Reported-by: Jan Kara
Signed-off-by: Matthew Wilcox
---
fs/dax.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/dax.c b/fs/dax.c
index 9bcce89ea18e..e69fc231833b 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -365,7 +365,7 @@ bool dax_lock_mapping_entry
Fixes: c2a7d2a11552 ("filesystem-dax: Introduce dax_lock_mapping_entry()")
Cc: sta...@vger.kernel.org
Signed-off-by: Matthew Wilcox
---
fs/dax.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index e69fc231833b..cf1805645d
These both fix race conditions in dax_lock_mapping_entry(). I've tagged
them both for 4.19 backport, which will fail and I'll do the equivalent
patch for it. Dan, do you want to take these through your tree?
Matthew Wilcox (2):
dax: Check page->mapping isn't NULL
dax: Do
On Wed, Nov 28, 2018 at 09:08:40AM -0800, Dan Williams wrote:
> > Can we add a comment here like:
> >
> > /*
> > * Entry lock waits are exclusive. Wake up the next waiter since we
> > * aren't sure we will acquire the entry lock and thus wake the
> > * next waiter
On Thu, Nov 29, 2018 at 04:13:46PM -0800, Dan Williams wrote:
> Internal to dax_unlock_mapping_entry(), dax_unlock_entry() is used to
> store a replacement entry in the Xarray at the given xas-index with the
> DAX_LOCKED bit clear. When called, dax_unlock_entry() expects the unlocked
> value of the
On Fri, Nov 30, 2018 at 07:54:49AM -0800, Dan Williams wrote:
> Looks good to me, although can we make that cookie an actual type? I
> think it's mostly ok to pass around (void *) for 'entry' inside of
> fs/dax.c, but once an entry leaves that file I'd like it to have an
> explicit type to catch pe
On Fri, Nov 30, 2018 at 09:01:07AM -0800, Dan Williams wrote:
> On Fri, Nov 30, 2018 at 8:33 AM Dan Williams wrote:
> >
> > On Fri, Nov 30, 2018 at 8:24 AM Matthew Wilcox wrote:
> > >
> > > On Fri, Nov 30, 2018 at 07:54:49AM -0800, Dan Williams wrote:
> >
I.e. offload the responsibility of conveying
> that this is not the traditional page lock to the fact that a
> dax_entry is returned and passed back to the unlock routine.
From: Matthew Wilcox
Date: Fri, 30 Nov 2018 11:05:06 -0500
Subject: [PATCH] dax: Change lock/unlock API
Return the u
On Thu, Dec 06, 2018 at 12:32:47PM +, Kieran Bingham wrote:
> On 04/12/2018 20:47, Luis Chamberlain wrote:
> > On Mon, Dec 03, 2018 at 03:48:15PM -0800, Brendan Higgins wrote:
> >> On Thu, Nov 29, 2018 at 5:54 AM Kieran Bingham
> >> wrote:
> >>>
> >>> Hi Brendan,
> >>>
> >>> Thanks again for t
On Sun, Dec 09, 2018 at 10:26:54AM -0800, Dan Williams wrote:
> [ add Willy and Jan ]
>
> On Sun, Dec 9, 2018 at 10:02 AM Linus Torvalds
> wrote:
> >
> > On Sat, Dec 8, 2018 at 10:26 PM Williams, Dan J
> > wrote:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
> > > ta
> id to .
I have only compile-tested this backport. Dan, do you want to run it
through some tests before Greg applies it?
>From e01d37913b5577acaa2e8e35200081eae2795087 Mon Sep 17 00:00:00 2001
From: Matthew Wilcox
Date: Tue, 11 Dec 2018 10:16:45 -0500
Subject: [PATCH 2/2] dax: Don'
On Mon, Jan 14, 2019 at 10:29:02AM +1100, Dave Chinner wrote:
> Until you have images (and hence host page cache) shared between
> multiple guests. People will want to do this, because it means they
> only need a single set of pages in host memory for executable
> binaries rather than a set of page
On Thu, Feb 14, 2019 at 11:31:24AM -0800, Dan Williams wrote:
> On Thu, Feb 14, 2019 at 11:10 AM Jerome Glisse wrote:
> > I am just again working on my struct page mapping patchset as well as
> > the generic page write protection that sits on top. I hope to be able
> > to post the v2 in couple wee
On Fri, Feb 15, 2019 at 06:08:15PM -0800, Dan Williams wrote:
> Hi Willy,
>
> Piotr reports the following crash can be triggered on latest mainline:
>
> EXT4-fs (pmem5): recovery complete
> EXT4-fs (pmem5): mounted filesystem with ordered data mode. Opts: dax
> [ cut here ]
On Sat, Feb 16, 2019 at 07:35:11AM -0800, Matthew Wilcox wrote:
> Another way to fix this would be to mask the address in dax_entry_mkclean(),
> but I think this is cleaner.
That's clearly rubbish, dax_entry_mkclean() can't possibly mask the
address. It might be mis-aligned in
On Sat, Feb 16, 2019 at 09:29:48AM -0800, Matthew Wilcox wrote:
> On Sat, Feb 16, 2019 at 07:35:11AM -0800, Matthew Wilcox wrote:
> > Another way to fix this would be to mask the address in dax_entry_mkclean(),
> > but I think this is cleaner.
>
> That's clearly rubbish,
On Mon, Feb 25, 2019 at 09:03:00PM -0800, Dan Williams wrote:
> On Sat, Feb 16, 2019 at 1:11 PM Matthew Wilcox wrote:
> >
> > On Sat, Feb 16, 2019 at 09:29:48AM -0800, Matthew Wilcox wrote:
> > > On Sat, Feb 16, 2019 at 07:35:11AM -0800, Matthew Wilcox wrote:
> > >
On Tue, Feb 26, 2019 at 04:08:21AM -0800, Matthew Wilcox wrote:
> On Mon, Feb 25, 2019 at 09:03:00PM -0800, Dan Williams wrote:
> > On Sat, Feb 16, 2019 at 1:11 PM Matthew Wilcox wrote:
> > >
> > > On Sat, Feb 16, 2019 at 09:29:48AM -0800, Matthew Wilcox wrote:
> &g
range.
Fixes: c1901cd33cf4 "page cache: Convert find_get_entries_tag to XArray"
Reported-by: Piotr Balcer
Tested-by: Dan Williams
Signed-off-by: Matthew Wilcox
---
fs/dax.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/fs/dax.c b/fs/d
range.
Fixes: c1901cd33cf4 "page cache: Convert find_get_entries_tag to XArray"
Reported-by: Piotr Balcer
Tested-by: Dan Williams
Signed-off-by: Matthew Wilcox
---
fs/dax.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/fs/dax.c b/fs/d
On Fri, Mar 01, 2019 at 02:49:54PM +0100, Jan Kara wrote:
> > pfn = dax_to_pfn(entry);
> > - size = PAGE_SIZE << dax_entry_order(entry);
> > + count = 1UL << dax_entry_order(entry);
> > + index = xas->xa_index &~ (count - 1);
>
> Hum, why do you compute 'index' here when you actually nev
On Thu, Mar 07, 2019 at 10:16:17PM -0800, Dan Williams wrote:
> Hi Willy,
>
> We're seeing a case where RocksDB hangs and becomes defunct when
> trying to kill the process. v4.19 succeeds and v4.20 fails. Robert was
> able to bisect this to commit b15cd800682f "dax: Convert page fault
> handlers t
On Thu, Apr 04, 2019 at 12:08:38PM -0700, Dan Williams wrote:
> +++ b/lib/Kconfig
> @@ -318,6 +318,12 @@ config DECOMPRESS_LZ4
> config GENERIC_ALLOCATOR
> bool
>
> +#
> +# Generic IDA for memory regions
> +#
Leaky abstraction -- nobody needs know that it's implemented as an IDA.
Suggest:
On Wed, Apr 24, 2019 at 10:13:15AM -0700, Dan Williams wrote:
> I think unaligned addresses have always been passed to
> vmf_insert_pfn_pmd(), but nothing cared until this patch. I *think*
> the only change needed is the following, thoughts?
>
> diff --git a/fs/dax.c b/fs/dax.c
> index ca0671d55aa
On Tue, Apr 20, 2021 at 06:00:49PM +0300, Mike Rapoport wrote:
> + mapping = (struct address_space *)
> + ((unsigned long)page->mapping & ~PAGE_MAPPING_FLAGS);
> +
> + if (mapping != page->mapping)
> + return false;
> +
> + return page->mapping->a_ops == &secretm
On Fri, Jan 10, 2020 at 07:03:04PM +, Joao Martins wrote:
> +++ b/arch/x86/include/asm/pgtable.h
> @@ -293,6 +293,15 @@ static inline int pgd_devmap(pgd_t pgd)
> {
> return 0;
> }
> +#endif
> +
> +#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
> +static inline int pmd_special(pmd_t pmd)
> +{
> +
On Fri, Jan 10, 2020 at 07:03:05PM +, Joao Martins wrote:
> @@ -4366,6 +4366,7 @@ EXPORT_SYMBOL(follow_pte_pmd);
> int follow_pfn(struct vm_area_struct *vma, unsigned long address,
> unsigned long *pfn)
> {
> + pmd_t *pmdpp = NULL;
Please rename to 'pmdp'.
_
On Wed, Feb 12, 2020 at 12:07:28PM -0500, Vivek Goyal wrote:
> +int dax_pgoff(sector_t dax_offset, sector_t sector, size_t size, pgoff_t
> *pgoff)
> +{
> + phys_addr_t phys_off = (dax_offset + sector) * 512;
> +
> + if (pgoff)
> + *pgoff = PHYS_PFN(phys_off);
> + if (phys_o
On Mon, Feb 24, 2020 at 03:34:07PM +1100, Alastair D'Silva wrote:
> V3:
> - Rebase against next/next-20200220
> - Move driver to arch/powerpc/platforms/powernv, we now expect this
> driver to go upstream via the powerpc tree
That's rather the opposite direction of normal; mostly drivers li
On Fri, Mar 27, 2020 at 06:11:47PM +1100, Alastair D'Silva wrote:
> +static struct mutex minors_idr_lock;
> +static struct idr minors_idr;
...
> + mutex_lock(&minors_idr_lock);
> + minor = idr_alloc(&minors_idr, ocxlpmem, 0, NUM_MINORS, GFP_KERNEL);
> + mutex_unlock(&minors_idr_lock);
.
On Sat, Mar 28, 2020 at 07:56:17PM -0700, Matthew Wilcox wrote:
> On Fri, Mar 27, 2020 at 06:11:47PM +1100, Alastair D'Silva wrote:
> > +static struct mutex minors_idr_lock;
> > +static struct idr minors_idr;
> ...
> > + mutex_lock(&minors_idr_lock);
>
On Sat, Apr 18, 2020 at 11:41:07AM -0700, Randy Dunlap wrote:
> +++ linux-next-20200327/drivers/usb/core/sysfs.c
> @@ -1263,7 +1263,7 @@ void usb_create_sysfs_intf_files(struct
> if (!alt->string && !(udev->quirks & USB_QUIRK_CONFIG_INTF_STRINGS))
> alt->string = usb_cache_strin
On Sat, Apr 18, 2020 at 11:41:09AM -0700, Randy Dunlap wrote:
> @@ -294,11 +295,11 @@ void dev_coredumpm(struct device *dev, s
>
> if (sysfs_create_link(&devcd->devcd_dev.kobj, &dev->kobj,
> "failing_device"))
> - /* nothing - symlink will be missing
On Sat, Apr 18, 2020 at 11:55:05AM -0700, Joe Perches wrote:
> On Sat, 2020-04-18 at 11:53 -0700, Randy Dunlap wrote:
> > On 4/18/20 11:50 AM, Matthew Wilcox wrote:
> > > On Sat, Apr 18, 2020 at 11:41:09AM -0700, Randy Dunlap wrote:
> > > > @@ -294,11 +295,11 @@ vo
On Mon, Apr 27, 2020 at 04:47:42PM +0800, Shiyang Ruan wrote:
> This patchset is a try to resolve the shared 'page cache' problem for
> fsdax.
>
> In order to track multiple mappings and indexes on one page, I
> introduced a dax-rmap rb-tree to manage the relationship. A dax entry
> will be assoc
On Tue, Apr 28, 2020 at 05:32:41PM +0800, Ruan Shiyang wrote:
> On 2020/4/28 下午2:43, Dave Chinner wrote:
> > On Tue, Apr 28, 2020 at 06:09:47AM +, Ruan, Shiyang wrote:
> > > 在 2020/4/27 20:28:36, "Matthew Wilcox" 写道:
> > > > On Mon, Apr 27, 2020
Hardware actually tells us the blast radius of the error, but we ignore
it and take out the entire page. We've had a customer request to know
exactly how much of the page is damaged so they can avoid reconstructing
an entire 2MB page if only a single cacheline is damaged.
This is only a strawma
On Tue, Jun 23, 2020 at 03:04:12PM -0700, Luck, Tony wrote:
> On Tue, Jun 23, 2020 at 09:17:45PM +0100, Matthew Wilcox wrote:
> > Hardware actually tells us the blast radius of the error, but we ignore
> > it and take out the entire page. We've had a customer request to know
On Tue, Jun 23, 2020 at 03:26:58PM -0700, Luck, Tony wrote:
> On Tue, Jun 23, 2020 at 11:17:41PM +0100, Matthew Wilcox wrote:
> > It might also be nice to have an madvise() MADV_ZERO option so the
> > application doesn't have to look up the fd associated with that memory
>
On Tue, Jun 23, 2020 at 05:01:24PM -0700, Darrick J. Wong wrote:
> On Tue, Jun 23, 2020 at 11:40:27PM +0100, Matthew Wilcox wrote:
> > On Tue, Jun 23, 2020 at 03:26:58PM -0700, Luck, Tony wrote:
> > > On Tue, Jun 23, 2020 at 11:17:41PM +0100, Matthew Wilcox wrote:
> > >
On Wed, Jun 24, 2020 at 04:21:24PM -0700, Dan Williams wrote:
> On Wed, Jun 24, 2020 at 5:10 AM Matthew Wilcox wrote:
> > On Tue, Jun 23, 2020 at 05:01:24PM -0700, Darrick J. Wong wrote:
> > > Frankly, I've wondered why the filesystem shouldn't just be in charge of
&g
On Thu, Jul 09, 2020 at 10:06:27AM +0800, Jia He wrote:
> After a general version of __weak memory_add_physaddr_to_nid implemented
> and exported , it is no use exporting twice in arch directory even if
> e,g, ia64/x86 have their specific version.
>
> This is to suppress the modpost warning:
> WAR
On Fri, Aug 07, 2020 at 09:13:28PM +0800, Shiyang Ruan wrote:
> This patchset is a try to resolve the problem of tracking shared page
> for fsdax.
>
> Instead of per-page tracking method, this patchset introduces a query
> interface: get_shared_files(), which is implemented by each FS, to
> obtain
On Mon, Aug 10, 2020 at 04:15:50PM +0800, Ruan Shiyang wrote:
>
>
> On 2020/8/7 下午9:38, Matthew Wilcox wrote:
> > On Fri, Aug 07, 2020 at 09:13:28PM +0800, Shiyang Ruan wrote:
> > > This patchset is a try to resolve the problem of tracking shared page
> > > for f
On Fri, Aug 07, 2020 at 02:24:00AM +0300, Kirill A. Shutemov wrote:
> On Tue, Aug 04, 2020 at 05:17:52PM +0100, Matthew Wilcox (Oracle) wrote:
> > diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
> > index 484a36185bb5..a474a92a2a72 100644
> > --- a/include/linu
On Tue, Aug 25, 2020 at 09:59:18AM +1000, Dave Chinner wrote:
> On Mon, Aug 24, 2020 at 03:55:06PM +0100, Matthew Wilcox (Oracle) wrote:
> > static inline struct iomap_page *to_iomap_page(struct page *page)
> > {
> > + VM_BUG_ON_PGFLAGS(PageTail(page), page);
> >
On Tue, Aug 25, 2020 at 10:12:23AM +1000, Dave Chinner wrote:
> > -static int
> > -__iomap_write_end(struct inode *inode, loff_t pos, unsigned len,
> > - unsigned copied, struct page *page)
> > +static size_t __iomap_write_end(struct inode *inode, loff_t pos, size_t
> > len,
> > +
On Tue, Aug 25, 2020 at 10:27:35AM +1000, Dave Chinner wrote:
> > do {
> > - unsigned offset, bytes;
> > -
> > - offset = offset_in_page(pos);
> > - bytes = min_t(loff_t, PAGE_SIZE - offset, count);
> > + loff_t bytes;
> >
> > if (IS_DAX(ino
On Tue, Aug 25, 2020 at 02:27:11PM +1000, Dave Chinner wrote:
> On Mon, Aug 24, 2020 at 09:35:59PM -0600, Andreas Dilger wrote:
> > On Aug 24, 2020, at 9:26 PM, Matthew Wilcox wrote:
> > >
> > > On Tue, Aug 25, 2020 at 10:27:35AM +1000, Dave Chinne
On Tue, Aug 25, 2020 at 02:02:03PM -0700, Darrick J. Wong wrote:
> > /*
> > - * Structure allocated for each page when block size < PAGE_SIZE to track
> > + * Structure allocated for each page when block size < page size to track
> > * sub-page uptodate status and I/O completions.
>
> "for each
On Tue, Sep 15, 2020 at 08:34:41AM -0400, Mikulas Patocka wrote:
> - when the fsck.nvfs tool mmaps the device /dev/pmem0, the kernel uses
> buffer cache for the mapping. The buffer cache slows does fsck by a factor
> of 5 to 10. Could it be possible to change the kernel so that it maps DAX
> bas
On Tue, Sep 15, 2020 at 03:40:52PM +, David Laight wrote:
> > @@ -147,7 +147,7 @@ iomap_iop_set_range_uptodate(struct page *page,
> > unsigned off, unsigned len)
> > unsigned int i;
> >
> > spin_lock_irqsave(&iop->uptodate_lock, flags);
> > - for (i = 0; i < PAGE_SIZE / i_blocksize(
On Mon, Dec 18, 2017 at 01:35:47PM -0700, Ross Zwisler wrote:
> What I'm hoping to do with this series is to just provide a sysfs
> representation of the HMAT so that applications can know which NUMA nodes to
> select with existing utilities like numactl. This series does not currently
> alter any
On Wed, Dec 20, 2017 at 12:22:21PM -0800, Dave Hansen wrote:
> On 12/20/2017 10:19 AM, Matthew Wilcox wrote:
> > I don't know what the right interface is, but my laptop has a set of
> > /sys/devices/system/memory/memoryN/ directories. Perhaps this is the
> > right pla
On Sat, Dec 23, 2017 at 04:56:59PM -0800, Dan Williams wrote:
> +int dax_set_page_dirty(struct page *page)
> +{
> + /*
> + * Unlike __set_page_dirty_no_writeback, dax does all dirty
> + * tracking in the radix in response to mkwrite faults.
Please stop saying "in the radix". I think
On Wed, Dec 27, 2017 at 10:10:34AM +0100, Brice Goglin wrote:
> > Perhaps we can enlist /proc/iomem or a similar enumeration interface
> > to tell userspace the NUMA node and whether the kernel thinks it has
> > better or worse performance characteristics relative to base
> > system-RAM, i.e. new I
On Mon, Apr 16, 2018 at 09:14:48AM -0700, Dan Williams wrote:
> > - rc = vm_insert_mixed(vmf->vma, vmf->address, pfn);
> > -
> > - if (rc == -ENOMEM)
> > - return VM_FAULT_OOM;
> > - if (rc < 0 && rc != -EBUSY)
> > - return VM_FAULT_SIGBUS;
> > -
> > -
On Mon, Apr 16, 2018 at 11:00:26AM -0700, Dan Williams wrote:
> On Mon, Apr 16, 2018 at 10:47 AM, Matthew Wilcox wrote:
> > On Mon, Apr 16, 2018 at 09:14:48AM -0700, Dan Williams wrote:
> >> > - rc = vm_insert_mixed(vmf->vma, vmf->address, pfn);
> >>
On Mon, Apr 16, 2018 at 05:02:00PM -0600, Ross Zwisler wrote:
> I'm not sure what you mean by "vm_fault_t will become a distinct type"? Do
> you mean you'll make it into an enum, i.e.:
>
> enum vm_fault_t {
> VM_FAULT_OOM= 0x0001,
> VM_FAULT_SIGBUS = 0x0002,
>
On Mon, Apr 16, 2018 at 08:14:22PM -0400, Theodore Y. Ts'o wrote:
> On Mon, Apr 16, 2018 at 09:14:48AM -0700, Dan Williams wrote:
> > Ugh, so this change to vmf_insert_mixed() went upstream without fixing
> > the users? This changelog is now misleading as it does not mention
> > that is now an urge
On Fri, Apr 27, 2018 at 01:37:02AM -0700, David Rientjes wrote:
> On Fri, 27 Apr 2018, Souptick Joarder wrote:
>
> > Hi Matthew/ Ross,
> >
> > There are two changes exist in mm/huge_memory.c as part of this
> > patch. vmf_insert_pfn_pmd() and vmf_insert_pfn_pud() functions are
> > invoked from th
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
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 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
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
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 b
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
> > >
I plucked this patch from my XArray work. It seems self-contained enough
that it could go into the DAX tree for merging this cycle.
>From 8cb56f4ba36af38814ca7b8ba030a66384e59a21 Mon Sep 17 00:00:00 2001
From: Matthew Wilcox
Date: Thu, 29 Mar 2018 22:41:18 -0400
Subject: [PATCH] dax: Fix
Another bugfix from the XArray work; please queue for merge.
>From 4a53cab1968d2a1022f35d00b29519970ef624e9 Mon Sep 17 00:00:00 2001
From: Matthew Wilcox
Date: Thu, 29 Mar 2018 22:47:50 -0400
Subject: [PATCH] dax: dax_insert_mapping_entry always succeeds
It does not return an error, so
On Thu, May 17, 2018 at 12:32:07PM -0700, Dan Williams wrote:
> On Thu, May 17, 2018 at 11:37 AM, Matthew Wilcox wrote:
> >
> > I plucked this patch from my XArray work. It seems self-contained enough
> > that it could go into the DAX tree for merging thi
On Thu, May 17, 2018 at 01:29:10PM -0600, Ross Zwisler wrote:
> On Thu, May 17, 2018 at 01:24:00PM -0600, Ross Zwisler wrote:
> > On Thu, May 17, 2018 at 11:37:11AM -0700, Matthew Wilcox wrote:
> > >
> > > I plucked this patch from my XArray work. It seems self-con
I haven't got a filesystem mounted using DAX yet, but I thought I might
as well send out the current patch against ktest for enabling persistent
memory. It's clearly *wrong*, but I do get a /dev/pmem0 device under
Linux once I add all the right config options. So it's a start, and
people who ar
On Thu, Jul 05, 2018 at 07:46:05AM -0700, Dan Williams wrote:
> On Thu, Jul 5, 2018 at 1:29 AM, Johannes Thumshirn wrote:
> > On Wed, Jul 04, 2018 at 11:50:13PM -0700, Dan Williams wrote:
> >> +static ssize_t memmap_state_store(struct device *dev,
> >> + struct device_attribute *attr,
On Thu, Jul 05, 2018 at 01:24:55PM -0700, Andrew Morton wrote:
> On Thu, 5 Jul 2018 16:49:41 +0200 Johannes Thumshirn
> wrote:
>
> > On Thu, Jul 05, 2018 at 07:46:05AM -0700, Dan Williams wrote:
> > > ...but that also allows 'echo "syncAndThenSomeGarbage" >
> > > /sys/.../memmap_state' to succee
On Thu, May 03, 2018 at 01:24:26PM -0600, Ross Zwisler wrote:
> The following commit
>
> commit c6ce3e2fe3da ("radix tree test suite: Add config option for map
> shift")
>
> Introduced a phony makefile target called 'mapshift' that ends up
> generating the file generated/map-shift.h. This ph
On Mon, Jul 16, 2018 at 03:08:20PM -0600, Ross Zwisler wrote:
> On Mon, Jul 16, 2018 at 12:52:49PM -0700, Matthew Wilcox wrote:
> > On Mon, Jul 16, 2018 at 10:07:10AM -0600, Ross Zwisler wrote:
> <>
> > OK ... what version of make are you using? Because this works fin
On Mon, Jul 16, 2018 at 10:07:10AM -0600, Ross Zwisler wrote:
> Incidentally, in the current linux/master the radix tree test suite again
> fails to build:
>
> $ make
> sed -e 's/^static //' -e 's/__always_inline //' -e 's/inline //' <
> ../../../lib/radix-tree.c > radix-tree.c
> sed -e 's/
On Wed, Jul 18, 2018 at 02:27:31PM -0400, Jeff Moyer wrote:
> Hi, Dave,
>
> Dave Jiang writes:
>
> > When pmem namespaces created are smaller than section size, this can cause
> > issue during removal and gpf was observed:
> >
> > Add code to check whether we have mapping already in the same sec
On Fri, Jul 27, 2018 at 03:17:27PM -0600, Jane Chu wrote:
> +++ b/include/linux/mm.h
> @@ -387,6 +387,13 @@ enum page_entry_size {
> * These are the virtual MM functions - opening of an area, closing and
> * unmapping it (needed to keep files on disk up-to-date etc), pointer
> * to the functi
On Thu, Sep 17, 2020 at 03:05:00PM -0700, Darrick J. Wong wrote:
> > -static loff_t
> > -iomap_zero_range_actor(struct inode *inode, loff_t pos, loff_t count,
> > - void *data, struct iomap *iomap, struct iomap *srcmap)
> > +static loff_t iomap_zero_range_actor(struct inode *inode, loff_t
On Mon, Sep 21, 2020 at 12:20:42PM -0400, Mikulas Patocka wrote:
> The same for directories - NVFS hashes the file name and uses radix-tree
> to locate a directory page where the directory entry is located. XFS
> b+trees would result in much more accesses than the radix-tree.
What? Radix trees
On Tue, Sep 22, 2020 at 12:23:45PM -0400, Qian Cai wrote:
> On Fri, 2020-09-11 at 00:47 +0100, Matthew Wilcox (Oracle) wrote:
> > Size the uptodate array dynamically to support larger pages in the
> > page cache. With a 64kB page, we're only saving 8 bytes per page today
On Tue, Sep 22, 2020 at 12:46:05PM -0400, Mikulas Patocka wrote:
> I agree that the b+tree were a good choice for XFS.
>
> In RAM-based maps, red-black trees or avl trees are used often. In
> disk-based maps, btrees or b+trees are used. That's because in RAM, you
> are optimizing for the number
On Tue, Sep 22, 2020 at 09:06:03PM -0400, Qian Cai wrote:
> On Tue, 2020-09-22 at 18:05 +0100, Matthew Wilcox wrote:
> > On Tue, Sep 22, 2020 at 12:23:45PM -0400, Qian Cai wrote:
> > > On Fri, 2020-09-11 at 00:47 +0100, Matthew Wilcox (Oracle) wrote:
> > > > Size the
On Wed, Sep 23, 2020 at 09:11:43AM -0400, Mikulas Patocka wrote:
> I also don't know how to implement journling on persistent memory :) On
> EXT4 or XFS you can pin dirty buffers in memory until the journal is
> flushed. This is obviously impossible on persistent memory. So, I'm
> considering im
On Tue, Sep 22, 2020 at 10:00:01PM -0700, Darrick J. Wong wrote:
> On Wed, Sep 23, 2020 at 03:48:59AM +0100, Matthew Wilcox wrote:
> > On Tue, Sep 22, 2020 at 09:06:03PM -0400, Qian Cai wrote:
> > > On Tue, 2020-09-22 at 18:05 +0100, Matthew Wilcox wrote:
> > > > On T
On Tue, Sep 22, 2020 at 06:05:26PM +0100, Matthew Wilcox wrote:
> On Tue, Sep 22, 2020 at 12:23:45PM -0400, Qian Cai wrote:
> > On Fri, 2020-09-11 at 00:47 +0100, Matthew Wilcox (Oracle) wrote:
> > > Size the uptodate array dynamically to support larger pages in the
> > &g
On Wed, Sep 30, 2020 at 01:27:45PM +0300, Mike Rapoport wrote:
> On Tue, Sep 29, 2020 at 05:15:52PM +0200, Peter Zijlstra wrote:
> > On Tue, Sep 29, 2020 at 05:58:13PM +0300, Mike Rapoport wrote:
> > > On Tue, Sep 29, 2020 at 04:12:16PM +0200, Peter Zijlstra wrote:
> >
> > > > It will drop them do
On Thu, Aug 06, 2020 at 08:16:02PM +, Verma, Vishal L wrote:
> On Thu, 2020-08-06 at 19:44 +, Verma, Vishal L wrote:
> > >
> > > I'm running xfstests on this patchset right now. If one of the DAX
> > > people could try it out, that'd be fantastic.
On Fri, Oct 09, 2020 at 02:34:34PM -0700, Eric Biggers wrote:
> On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote:
> > The kmap() calls in this FS are localized to a single thread. To avoid
> > the over head of global PKRS updates use the new kmap_thread() call.
> >
> > @@ -2410,
1 - 100 of 254 matches
Mail list logo
