On Wed, 26 Sep 2018 08:36:47 -0700 Dave Hansen wrote:
> On 09/26/2018 12:38 AM, Michal Hocko wrote:
> > Why cannot you simply go with [no]vm_page_poison[=on/off]?
>
> I was trying to look to the future a bit, if we end up with five or six
> more other options we want to allow folks to enable/dis
On Wed, 5 Dec 2018 21:42:47 +0100 Michal Hocko wrote:
> > I got your explanation. However Andrew had already applied the patches
> > and I had some outstanding issues in them that needed to be addressed.
> > So I thought it best to send out this set of patches with those fixes
> > before the code
On Tue, 12 Mar 2019 15:50:36 -0700 Alexander Duyck
wrote:
> On Tue, 2019-03-12 at 15:07 -0700, Andrew Morton wrote:
> > On Wed, 5 Dec 2018 21:42:47 +0100 Michal Hocko wrote:
> >
> > > > I got your explanation. However Andrew had already applied the patches
> &g
On Wed, 17 Apr 2019 11:39:52 -0700 Dan Williams
wrote:
> At namespace creation time there is the potential for the "expected to
> be zero" fields of a 'pfn' info-block to be filled with indeterminate
> data. While the kernel buffer is zeroed on allocation it is immediately
> overwritten by nd_pf
On Wed, 17 Apr 2019 11:38:55 -0700 Dan Williams
wrote:
> The memory hotplug section is an arbitrary / convenient unit for memory
> hotplug. 'Section-size' units have bled into the user interface
> ('memblock' sysfs) and can not be changed without breaking existing
> userspace. The section-size c
On Tue, 18 May 2021 10:20:31 +0300 Mike Rapoport wrote:
> From: Mike Rapoport
>
> Introduce "memfd_secret" system call with the ability to create memory
> areas visible only in the context of the owning process and not mapped not
> only to other processes but in the kernel page tables as well.
On Tue, 3 Dec 2019 15:42:28 +0530 "Aneesh Kumar K.V"
wrote:
> On 12/3/19 6:20 AM, Dan Williams wrote:
> > On Sat, Nov 30, 2019 at 3:13 PM Andrew Morton
> > wrote:
> >>
> >> On Wed, 25 Sep 2019 09:21:02 +0530 "Aneesh Kumar K.V"
> >
On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand wrote:
> >
> > Why does the firmware map support hotplug entries?
>
> I assume:
>
> The firmware memmap was added primarily for x86-64 kexec (and still, is
> mostly used on x86-64 only IIRC). There, we had ACPI hotplug. When DIMMs
> get hotp
On Fri, 8 May 2020 10:42:14 +0200 David Hildenbrand wrote:
> Assume we have kmem configured and loaded:
> [root@localhost ~]# cat /proc/iomem
> ...
> 14000-33fff : Persistent Memory$
> 14000-1481f : namespace0.0
> 15000-33fff : dax0.0
> 15000-33fff
On Sun, 02 Aug 2020 22:03:46 -0700 Dan Williams
wrote:
> Make the device-dax 'size' attribute writable to allow capacity to be
> split between multiple instances in a region. The intended consumers of
> this capability are users that want to split a scarce memory resource
> between device-dax an
On Wed, 19 Aug 2020 18:53:57 -0700 Dan Williams
wrote:
> > I think I am missing some important pieces. Bear with me.
>
> No worries, also bear with me, I'm going to be offline intermittently
> until at least mid-September. Hopefully Joao and/or Vishal can jump in
> on this discussion.
Ordinari
On Tue, 11 Aug 2020 11:44:46 +0200 Roger Pau Monne wrote:
> This is in preparation for the logic behind MEMORY_DEVICE_DEVDAX also
> being used by non DAX devices.
Acked-by: Andrew Morton .
Please add it to the Xen tree when appropriate.
(I'm not sure what David means by "sep
On Thu, 01 Mar 2018 19:49:07 -0800 Dan Williams
wrote:
> When device-dax is operating in huge-page mode we want it to behave like
> hugetlbfs and report the MMU page mapping size that is being enforced by
> the vma. Similar to commit 31383c6865a5 "mm, hugetlbfs: introduce
> ->split() to vm_opera
On Tue, 8 May 2018 11:44:24 -0600 Ross Zwisler
wrote:
> On Thu, May 03, 2018 at 01:24:25PM -0600, Ross Zwisler wrote:
> > The following series gets the radix tree test suite compiling again in
> > the current linux/master, adds a unit test which exposes a race in the
> > radix tree multi-order i
On Thu, 10 May 2018 15:54:53 -0700 Dan Williams
wrote:
> > - The Fixes: tag
> > - The Reported-by
>
> Those were there.
>
> > - Jan's reviewed-by
>
> Right, Jan's came after I pushed it for -next soaking, but I updated it.
>
> > - the cc:stable tag
>
> That was there too, not sure where you
On Fri, 18 May 2018 18:35:08 -0700 Dan Williams
wrote:
> get_user_pages_fast() for device pages is missing the typical validation
> that all page references have been taken while the mapping was valid.
> Without this validation truncate operations can not reliably coordinate
> against new page r
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 succeed.
>
> Yep it does :-(.
>
> Damn
sysfs_streq()
__
On Fri, 6 Jul 2018 13:06:58 -0600 Ross Zwisler
wrote:
> commit 054620849110 ("mm/sparse.c: make sparse_init_one_section void and
> remove check")
>
> changed how the error handling in sparse_add_one_section() works.
>
> Previously sparse_index_init() could return -EEXIST, and the function wou
On Fri, 6 Jul 2018 15:54:37 -0600 Ross Zwisler
wrote:
> On Fri, Jul 06, 2018 at 11:23:27PM +0200, Oscar Salvador wrote:
> > On Fri, Jul 06, 2018 at 01:06:58PM -0600, Ross Zwisler wrote:
> > > The following commit in -next:
> > >
> > > commit 054620849110 ("mm/sparse.c: make sparse_init_one_sect
On Fri, 15 Jun 2018 13:33:39 -0700 Dave Jiang wrote:
> 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 section and
> prevent additional mapping from c
On Wed, 18 Jul 2018 10:49:44 +0800 Baoquan He wrote:
> For kexec_file loading, if kexec_buf.top_down is 'true', the memory which
> is used to load kernel/initrd/purgatory is supposed to be allocated from
> top to down. This is what we have been doing all along in the old kexec
> loading interface
On Thu, 19 Jul 2018 23:17:53 +0800 Baoquan He wrote:
> Hi Andrew,
>
> On 07/18/18 at 03:33pm, Andrew Morton wrote:
> > On Wed, 18 Jul 2018 10:49:44 +0800 Baoquan He wrote:
> >
> > > For kexec_file loading, if kexec_buf.top_down is 'true', the memory w
On Fri, 27 Jul 2018 15:17:27 -0600 Jane Chu wrote:
> Commit 05ea88608d4e13 (mm, hugetlbfs: introduce ->pagesize() to
> vm_operations_struct) adds a new ->pagesize() function to
> hugetlb_vm_ops, intended to cover all hugetlbfs backed files.
That was merged three months ago. Can you suggest why
On Wed, 16 Sep 2020 10:35:34 +0300 Mike Rapoport wrote:
> This is an implementation of "secret" mappings backed by a file descriptor.
> I've dropped the boot time reservation patch for now as it is not strictly
> required for the basic usage and can be easily added later either with or
> without
On Thu, 24 Sep 2020 16:28:58 +0300 Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
>
> This is an implementation of "secret" mappings backed by a file descriptor.
> I've dropped the boot time reservation patch for now as it is not strictly
> required for the basic usage and can be easily a
On Fri, 25 Sep 2020 12:13:04 -0700 Dan Williams
wrote:
> Introduce a device align attribute. While doing so, rename the region
> align attribute to be more explicitly named as so, but keep it named as
> @align to retain the API for tools like daxctl.
>
> Changes on align may not always be vali
On Sat, 17 Oct 2020 13:54:08 -0700 Dan Williams
wrote:
> On Sat, Oct 17, 2020 at 11:39 AM Linus Torvalds
> wrote:
> >
> > On Fri, Oct 16, 2020 at 2:10 PM Dan Williams
> > wrote:
> > >
> > > Link:
> > > http://lore.kernel.org/r/CAHk-=wgntlbvad8mntvh+gqyapnwex20pxhu_+frqevvq42...@mail.gmail.co
On Mon, 2 Nov 2020 15:52:39 -0800 Dan Williams wrote:
> The attached patch is going through some kbuild-robot exposure to make
> sure I did not break anything else.
I'll duck this for now - please send it along formally if/when testing
is successful.
_
On Tue, 10 Nov 2020 17:14:41 +0200 Mike Rapoport wrote:
> Account memory consumed by secretmem to memcg. The accounting is updated
> when the memory is actually allocated and freed.
From: Andrew Morton
Subject: secretmem-add-memcg-accounting-fix
fix CONFIG_MEMCG=n build
Cc: Mike Ra
On Thu, 3 Dec 2020 08:29:43 +0200 Mike Rapoport wrote:
> From: Mike Rapoport
>
> On arm64, set_direct_map_*() functions may return 0 without actually
> changing the linear map. This behaviour can be controlled using kernel
> parameters, so we need a way to determine at runtime whether calls to
On Thu, 3 Dec 2020 08:29:48 +0200 Mike Rapoport wrote:
> From: Mike Rapoport
>
> Wire up memfd_secret system call on architectures that define
> ARCH_HAS_SET_DIRECT_MAP, namely arm64, risc-v and x86.
>
> ...
>
> --- a/include/uapi/asm-generic/unistd.h
> +++ b/include/uapi/asm-generic/unistd.h
On Mon, 7 Dec 2020 18:00:06 +0200 Mike Rapoport wrote:
> >
> > I can't see where was it defined for arm64 after it looks like Andrew has
> > deleted the above chunk. Thus, we have a warning using this .config:
> >
> > https://cailca.coding.net/public/linux/mm/git/files/master/arm64.config
> >
soft-offline: convert parameter to pfn")
> Cc: Andrew Morton
> Cc: Naoya Horiguchi
> Cc: Michal Hocko
> Reviewed-by: David Hildenbrand
> Reviewed-by: Oscar Salvador
> Cc:
> Signed-off-by: Dan Williams
A cc:stable patch in the middle is awkward. I'll make this a
On Thu, 21 Jan 2021 14:27:12 +0200 Mike Rapoport wrote:
> @Andrew, this is based on v5.11-rc4-mmots-2021-01-19-13-54 with secretmem
> patches dropped from there, I can rebase whatever way you prefer.
Thanks. I merged this version.
Silently, to avoid spraying out all those emails again ;)
_
On Fri, 2 Apr 2021 14:16:04 -0700 (PDT) Hugh Dickins wrote:
> On Fri, 2 Apr 2021, Hugh Dickins wrote:
> >
> > There is a "Put holes back where they were" xas_store(&xas, NULL) on
> > the failure path, which I think we would expect to delete empty nodes.
> > But it only goes as far as nr_none. I
On Wed, 3 Mar 2021 18:22:00 +0200 Mike Rapoport wrote:
> This is an implementation of "secret" mappings backed by a file descriptor.
>
> The file descriptor backing secret memory mappings is created using a
> dedicated memfd_secret system call The desired protection mode for the
> memory is con
ing mode lookup for dax pfns always returns _PAGE_CACHE_MODE_UC. We do
> not
> use track_pfn_insert() in the dax-pte path, and we always want to use the
> pgprot of the vma itself, so drop this call.
>
> Cc: Ross Zwisler
> Cc: Matthew Wilcox
> Cc: Kirill A. Shutemov
> Cc
On Tue, 06 Sep 2016 09:49:47 -0700 Dan Williams
wrote:
> Now that track_pfn_insert() is no longer used in the DAX path, it no
> longer needs to comprehend pfn_t values.
What's the benefit in this? A pfn *should* have type pfn_t, shouldn't
it? Confused.
___
st be set for an
> anonymous transparent huge page, but are not set for the zone_device
> pages associated with dax mappings.
Acked-by: Andrew Morton
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
) does
> not. So, teach track_pfn_insert() and untrack_pfn() how to handle
> tracking without a vma, and arrange for devm_memremap_pages() to
> establish the write-back-cache reservation in the memtype tree.
Acked-by: Andrew Morton
I'll grab [2/2].
_
On Fri, 11 Nov 2016 20:21:41 -0800 Dan Williams
wrote:
> Mark dax vmas as not migratable to exclude them from task_numa_work().
> This is especially relevant for device-dax which wants to ensure
> predictable access latency and not incur periodic faults.
>
> ...
>
> @@ -177,6 +178,9 @@ static in
On Thu, 10 Nov 2016 14:11:57 -0800 Dan Williams
wrote:
> ZONE_DEVICE pages are mapped into a process via the filesystem-dax and
> device-dax mechanisms. There are also proposals to use ZONE_DEVICE
> pages for other usages outside of dax. Add statistics to smaps so
> applications can debug that
On Tue, 3 Jan 2017 17:13:49 -0700 Ross Zwisler
wrote:
> On Thu, Dec 22, 2016 at 02:18:52PM -0700, Ross Zwisler wrote:
> > Currently dax_mapping_entry_mkclean() fails to clean and write protect the
> > pmd_t of a DAX PMD entry during an *sync operation. This can result in
> > data loss, as detai
On Fri, 13 Jan 2017 16:34:18 -0700 Toshi Kani wrote:
> DAX IO path does not support iostat, but its metadata IO path does.
> Therefore, iostat shows metadata IO statistics only, which has been
> confusing to users.
>
> Add iostat support to the DAX read/write path.
>
> Note, iostat still does n
On Fri, 13 Jan 2017 23:09:58 + "Kani, Toshimitsu"
wrote:
> On Fri, 2017-01-13 at 14:54 -0800, Andrew Morton wrote:
> > On Fri, 13 Jan 2017 16:34:18 -0700 Toshi Kani
> > wrote:
> >
> > > DAX IO path does not support iostat, but its metadata IO
On Thu, 19 Jan 2017 14:07:13 -0800 Dan Williams
wrote:
> Prepare for hot{plug,remove} of sub-ranges of a section by tracking a
> section active bitmask, each bit representing 2MB (SECTION_SIZE (128M) /
> map_active bitmask length (64)).
>
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmz
On Thu, 26 Jan 2017 10:09:53 -0700 Dave Jiang wrote:
> The current transparent hugepage code only supports PMDs. This patch
> adds support for transparent use of PUDs with DAX. It does not include
> support for anonymous pages. x86 support code also added.
>
> Most of this patch simply paralle
write the condition checks for
> > >> better readability in preparation for adding another condition.
> > >>
> > >> Cc: Jan Kara
> > >> Cc: Andrew Morton
> > >> Reviewed-by: Ross Zwisler
> > >> [ross: fix logic to
On Fri, 23 Jun 2017 15:12:51 +0800 "Huang, Ying" wrote:
> From: Huang Ying
>
> Hi, Andrew, could you help me to check whether the overall design is
> reasonable?
>
> Hi, Johannes and Minchan, Thanks a lot for your review to the first
> step of the THP swap optimization! Could you help me to r
On Fri, 28 Jul 2017 10:31:43 -0700 Matthew Wilcox wrote:
> On Fri, Jul 28, 2017 at 10:56:01AM -0600, Ross Zwisler wrote:
> > Dan Williams and Christoph Hellwig have recently expressed doubt about
> > whether the rw_page() interface made sense for synchronous memory drivers
> > [1][2]. It's uncle
On Tue, 1 Aug 2017 13:48:48 +0200 Arnd Bergmann wrote:
> Removing the btt_rw_page/pmem_rw_page functions had a surprising
> side-effect of introducing a false-positive warning in another
> function, due to changed inlining decisions in gcc:
>
> In file included from drivers/nvdimm/pmem.c:36:0:
On Sun, 1 Oct 2017 16:15:06 -0700 Dan Williams wrote:
> On Sun, Oct 1, 2017 at 2:59 PM, Dave Chinner wrote:
> [..]
> > The "capacity tax" had nothing to do with it - the major problem
> > with self hosting struct pages was that page locks can be hot and
> > contention on them will rapidly burn t
On Fri, 6 Oct 2017 14:15:41 -0700 Matthew Wilcox wrote:
> When using FAT on a block device which supports rw_page, we can hit
> BUG_ON(!PageLocked(page)) in try_to_free_buffers(). This is because we
> call clean_buffers() after unlocking the page we've written. Introduce a
> new clean_page_buff
On Tue, 14 Nov 2017 11:56:34 -0800 Dan Williams
wrote:
> Until there is a solution to the dma-to-dax vs truncate problem it is
> not safe to allow long standing memory registrations against
> filesytem-dax vmas. Device-dax vmas do not have this problem and are
> explicitly allowed.
>
> This is
On Tue, 14 Nov 2017 11:56:34 -0800 Dan Williams
wrote:
> Until there is a solution to the dma-to-dax vs truncate problem it is
> not safe to allow long standing memory registrations against
> filesytem-dax vmas. Device-dax vmas do not have this problem and are
> explicitly allowed.
>
> This is
On Wed, 20 Jul 2016 17:13:02 -0600 Jonathan Corbet wrote:
> On Thu, 14 Jul 2016 15:40:48 -0600
> Ross Zwisler wrote:
>
> > These are originally from Matthew Wilcox and were part of his huge
> > "mm,fs,dax: Change ->pmd_fault to ->huge_fault" patch that was part of PUD
> > support.
> >
> > I'm
On Tue, 23 Aug 2016 12:43:20 -0600 Toshi Kani wrote:
> The following BUG was observed while starting up KVM with nvdimm
> device as memory-backend-file to /dev/dax.
>
> BUG: unable to handle kernel NULL pointer dereference at 0008
>
> ...
>
> devm_memremap_pages() calls for_each_dev
On Wed, 24 Aug 2016 14:37:12 -0600 Ross Zwisler
wrote:
> For DAX inodes we need to be careful to never have page cache pages in the
> mapping->page_tree. This radix tree should be composed only of DAX
> exceptional entries and zero pages.
>
> ltp's readahead02 test was triggering a warning bec
On Wed, 24 Aug 2016 16:14:29 -0600 Ross Zwisler
wrote:
> For DAX inodes we need to be careful to never have page cache pages in the
> mapping->page_tree. This radix tree should be composed only of DAX
> exceptional entries and zero pages.
>
> ltp's readahead02 test was triggering a warning bec
On Wed, 05 Jun 2019 14:58:58 -0700 Dan Williams
wrote:
> At namespace creation time there is the potential for the "expected to
> be zero" fields of a 'pfn' info-block to be filled with indeterminate
> data. While the kernel buffer is zeroed on allocation it is immediately
> overwritten by nd_pf
On Thu, 6 Jun 2019 15:06:26 -0700 Dan Williams wrote:
> On Thu, Jun 6, 2019 at 2:46 PM Andrew Morton
> wrote:
> >
> > On Wed, 05 Jun 2019 14:58:58 -0700 Dan Williams
> > wrote:
> >
> > > At namespace creation time there is the potential for the "
On Thu, 13 Jun 2019 14:24:20 -0600 Logan Gunthorpe wrote:
>
>
> On 2019-06-13 2:21 p.m., Dan Williams wrote:
> > On Thu, Jun 13, 2019 at 1:18 PM Logan Gunthorpe wrote:
> >>
> >>
> >>
> >> On 2019-06-13 12:27 p.m., Dan Williams wrote:
> >>> On Thu, Jun 13, 2019 at 2:43 AM Christoph Hellwig wro
On Mon, 1 Jul 2019 19:10:38 +0530 "Aneesh Kumar K.V"
wrote:
> Architectures like powerpc use different address range to map ioremap
> and vmalloc range. The memunmap() check used by the nvdimm layer was
> wrongly using is_vmalloc_addr() to check for ioremap range which fails for
> ppc64. This r
On Fri, 28 Jun 2019 12:14:44 -0700 Dan Williams
wrote:
> I believe -mm auto drops patches when they appear in the -next
> baseline. So it should "just work" to pull it into the series and send
> it along for -next inclusion.
Yup. Although it isn't very "auto" - I manually check that the patch
On Fri, 2 Aug 2019 10:32:30 +0200 Christoph Hellwig wrote:
> Andrew,
>
> I've seen you've queued this up in -mm, but the explicit intent here was
> to quickly merge this after -rc1 so that the move doesn't conflict with
> further development for 5.3.
Didn't know that.
> Any chance you could s
On Fri, 16 Aug 2019 08:54:34 +0200 Christoph Hellwig wrote:
> The kvmppc ultravisor code wants a device private memory pool that is
> system wide and not attached to a device. Instead of faking up one
> provide a low-level memremap_pages for it. Note that this function is
> not exported, and do
On Fri, 16 Aug 2019 08:54:31 +0200 Christoph Hellwig wrote:
> Just add a simple macro that passes a NULL dev argument to
> dev_request_free_mem_region, and call request_mem_region in the
> function for that particular case.
Nit:
> +struct resource *request_free_mem_region(struct resource *base,
On Tue, 17 Sep 2019 21:01:29 +0530 "Aneesh Kumar K.V"
wrote:
> vmem_altmap_offset() adjust the section aligned base_pfn offset.
> So we need to make sure we account for the same when computing base_pfn.
>
> ie, for altmap_valid case, our pfn_first should be:
>
> pfn_first = altmap->base_pfn +
On Thu, 26 Sep 2019 17:55:51 +0530 "Aneesh Kumar K.V"
wrote:
> With altmap, all the resource pfns are not initialized. While initializing
> pfn, altmap reserve space is skipped. Hence when removing pfn from zone skip
> pfns that were never initialized.
>
> Update memunmap_pages to calculate sta
On Wed, 25 Sep 2019 09:21:02 +0530 "Aneesh Kumar K.V"
wrote:
> Andrew Morton writes:
>
> > On Tue, 17 Sep 2019 21:01:29 +0530 "Aneesh Kumar K.V"
> > wrote:
> >
> >> vmem_altmap_offset() adjust the section aligned base_pfn offset.
>
70 matches
Mail list logo
