On 07/06/2017 02:52 PM, Ross Zwisler wrote:
[...]
>
> The naming collision between Jerome's "Heterogeneous Memory Management
> (HMM)" and this "Heterogeneous Memory (HMEM)" series is unfortunate, but I
> was trying to stick with the word "Heterogeneous" because of the naming of
> the ACPI 6.2
On 07/06/2017 02:52 PM, Ross Zwisler wrote:
[...]
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index b1aacfc..31e3f20 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_ACPI_PROCESSOR)+= processor.o
> obj-$(CONFIG_ACPI)
em? Or is there more that must be done?
3. Christophe Hellwig's unified gup patchset wreaks havoc in gup.c, and will
conflict violently, as I'm sure you noticed. :)
thanks,
--
John Hubbard
NVIDIA
>
> A general overview follows for background.
>
> It should be noted that one soluti
device));
> - if (!devmem->resource)
> - return ERR_PTR(-ENOMEM);
> - break;
> - }
> - if (!devmem->resource)
> - return ERR_PTR(-ERANGE);
> -
> - devmem->resource->desc = IORES_DESC_DEVICE_PRIVATE_MEM
nd it's a good housecleaning here.
(As to the history: I know that there was some early "HMM dummy device"
testing when the HMM code was much younger, but such testing has long since
been superseded by more elaborate testing with real drivers.)
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
N
was unnecessary. I see from git history that it was
originally being set to NULL from within __put_devmap_managed_page(), and then
in commit 2fa147bdbf672c53386a8f5f2c7fe358004c3ef8, Dan moved it out of there,
and stashed in specifically here. But it appears to have been
On 6/13/19 2:43 AM, Christoph Hellwig wrote:
> noveau is currently using this through an odd hmm wrapper, and I plan
"nouveau"
> to switch it to the real thing later in this series.
>
> Signed-off-by: Christoph Hellwig
> ---
Reviewed-by: John Hubbard
thanks
s part of a future patchset to use that
kind of memory, but yes, we should not hesitate to clean house at this
point, and delete unused code.
thanks,
--
John Hubbard
NVIDIA
>
>>
>> So, yes, we really don't want any distro or something to turn this on
>> until it has a use.
&g
, then say Y.
config MIGRATE_VMA_HELPER
- bool
+ bool "migrate_vma() helper routine"
+ help
+ Provides a migrate_vma() routine that GPUs and other
+ device drivers may need.
config DEV_PAGEMAP_OPS
bool
thanks,
--
John Hubbard
NVIDIA
__
On 6/25/19 10:45 PM, Michal Hocko wrote:
> On Tue 25-06-19 20:15:28, John Hubbard wrote:
>> On 6/19/19 12:27 PM, Jason Gunthorpe wrote:
>>> On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote:
>>>> On 6/13/19 5:43 PM, Ira Weiny wrote:
>>>>> On
On 6/19/19 12:27 PM, Jason Gunthorpe wrote:
> On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote:
>> On 6/13/19 5:43 PM, Ira Weiny wrote:
>>> On Thu, Jun 13, 2019 at 07:58:29PM +, Jason Gunthorpe wrote:
>>>> On Thu, Jun 13, 2019 at 12:53:02
ddr_pin_user_pages()
...which also sounds close enough to get_user_pages() that a bit of
history and continuity is preserved, too.
thanks,
--
John Hubbard
NVIDIA
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
On 8/12/19 2:00 PM, Ira Weiny wrote:
On Fri, Aug 09, 2019 at 05:09:54PM -0700, John Hubbard wrote:
On 8/9/19 3:58 PM, ira.we...@intel.com wrote:
From: Ira Weiny
...
At one point I wanted to (and had in my tree) a new flag but I went away from
it. Prior to the discussion on mlock last week
.
+1 for these rules, assuming that we can make them work. They are
easy to explain and intuitive.
thanks,
--
John Hubbard
NVIDIA
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
On 8/19/19 6:20 PM, Dave Chinner wrote:
On Mon, Aug 19, 2019 at 05:05:53PM -0700, John Hubbard wrote:
On 8/19/19 2:24 AM, Dave Chinner wrote:
On Mon, Aug 19, 2019 at 08:34:12AM +0200, Jan Kara wrote:
On Sat 17-08-19 12:26:03, Dave Chinner wrote:
On Fri, Aug 16, 2019 at 12:05:28PM -0700, Ira
to add lease support
to drivers like XDP, which is otherwise looking pretty difficult to
set up with an fd. (It's socket-based, and not immediately clear where
to connect up the fd.)
thanks,
--
John Hubbard
NVIDIA
Why not just have a single table someplace of all the layout leases
with the file
On 8/19/19 8:36 PM, Dave Chinner wrote:
On Mon, Aug 19, 2019 at 08:09:33PM -0700, John Hubbard wrote:
On 8/19/19 6:20 PM, Dave Chinner wrote:
On Mon, Aug 19, 2019 at 05:05:53PM -0700, John Hubbard wrote:
On 8/19/19 2:24 AM, Dave Chinner wrote:
On Mon, Aug 19, 2019 at 08:34:12AM +0200, Jan
M *does* require those callbacks. Because we've been, so
far, equating FOLL_LONGTERM with the vaddr_pin struct and with a lease.
What am I missing here?
thanks,
--
John Hubbard
NVIDIA
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://list
low multiple processes to take FL_UNBREAKABLE
leases on the same file/range, so that we can make RDMA setups
reasonable. By "reasonable" I mean, "no need to have a lead process
that owns all the leases".
thanks,
--
John Hubbard
NVIDIA
gned long
> addr,
> + pmd_t *pmd, int flags, struct follow_page_context *ctx);
> +struct page *follow_devmap_pud(struct vm_area_struct *vma, unsigned long
> addr,
> + pud_t *pud, int flags, struct follow_page_context *ctx);
> +#else
> +static inline struct page *follow_devmap_pmd(struct vm_area_struct *vma,
> + unsigned long addr, pmd_t *pmd, int flags,
> + struct follow_page_context *ctx)
> +{
> + return NULL;
> +}
> +
> +static inline struct page *follow_devmap_pud(struct vm_area_struct *vma,
> + unsigned long addr, pud_t *pud, int flags,
> + struct follow_page_context *ctx)
> +{
> + return NULL;
> +}
> +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
> +
> +
> /*
> * The set of flags that only affect watermark checking and reclaim
> * behaviour. This is used by the MM to obey the caller constraints
>
thanks,
--
John Hubbard
NVIDIA
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
(-)
>
Looks good, although you may want to combine it with the next patch.
Otherwise it feels like a "to be continued" when you're reading them.
Either way, though:
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> ind
d memory within
> the address range.
>
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
> Signed-off-by: Ira Weiny
> ---
> mm/gup.c | 65 ++--
> 1 file changed, 40 insertions(+), 25 deletions(-)
>
> diff --git a/m
proper
> + * tracking.
> + */
> +void vaddr_unpin_pages_dirty_lock(struct page **pages, unsigned long
> nr_pages,
> + struct vaddr_pin *vaddr_pin, bool make_dirty)
> +{
> + __put_user_pages_dirty_lock(vaddr_pin, pages, nr_pages, make_dirty);
> +}
> +EXPORT_SYMBOL(vaddr_unpin_pages_dirty_lock);
>
OK, whew, I'm glad to see the updated _dirty_lock() API used here. :)
thanks,
--
John Hubbard
NVIDIA
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
lock);
>
> /**
> @@ -102,15 +162,7 @@ EXPORT_SYMBOL(put_user_pages_dirty_lock);
> */
> void put_user_pages(struct page **pages, unsigned long npages)
> {
> - unsigned long index;
> -
> - /*
> - * TODO: this can be optimized for huge pages: if a series of pages is
> - * physically contiguous and part of the same compound page, then a
> - * single operation to the head page should suffice.
> - */
> - for (index = 0; index < npages; index++)
> - put_user_page(pages[index]);
> + __put_user_pages(NULL, pages, npages);
> }
> EXPORT_SYMBOL(put_user_pages);
>
>
This all looks pretty good, so regardless of the outcome of the minor
points above,
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
w that we've simplified the API for it.
>
> Signed-off-by: Christoph Hellwig
> ---
> include/linux/hmm.h | 3 ---
> mm/hmm.c| 54 -
> 2 files changed, 57 deletions(-)
>
No objections here, good cleanup.
Reviewed-by:
eup.
Yes, the wakeup is only needed in the MEMORY_DEVICE_FSDAX case, but it
does no harm in the MEMORY_DEVICE_DEVDAX and MEMORY_DEVICE_PCI_P2PDMA
case.
Cc: Jan Kara
Cc: Christoph Hellwig
Cc: Ira Weiny
Cc: Jérôme Glisse
Cc: John Hubbard
Signed-off-by: Dan Williams
---
Hi John,
This appli
ks!
>
> John - can you please send a small series just doing the zone device
> patches rework? That way we can review it separately and maybe even get
> it into 5.5.
>
Sure.
thanks,
--
John Hubbard
NVIDIA
___
Linux-nvdimm mailing list
p is only needed in the MEMORY_DEVICE_FSDAX case, but it
does no harm in the MEMORY_DEVICE_DEVDAX and MEMORY_DEVICE_PCI_P2PDMA
case.
Cc: Jan Kara
Cc: Christoph Hellwig
Cc: Ira Weiny
Reviewed-by: Jérôme Glisse
Signed-off-by: Dan Williams
Signed-off-by: John Hubbard
---
drivers/nvdimm/pmem.c | 6
ig
Cc: Dan Williams
Suggested-by: Jérôme Glisse
Signed-off-by: Ira Weiny
Signed-off-by: John Hubbard
---
include/linux/mm.h | 27 ---
mm/memremap.c | 16 ++--
2 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/include/linux/mm.h b/incl
://lore.kernel.org/r/20191113042710.3997854-1-jhubb...@nvidia.com
Dan Williams (1):
mm: Cleanup __put_devmap_managed_page() vs ->page_free()
John Hubbard (1):
mm: devmap: refactor 1-based refcounting for ZONE_DEVICE pages
drivers/nvdimm/pmem.c | 6
include/linux/mm.h| 27 +++
lumsy
API design to *disable*, right?). And there is no hint about the scope.
And it *could* be so much more readable like this:
dev_access_enable(DEV_ACCESS_THIS_THREAD);
thanks,
--
John Hubbard
NVIDIA
___
Linux-nvdimm mailing list -- linux-nvd
FT or PUD_SHIFT for, that's a number-of-bits, isn't it?
Not a size. And if it's not a size, then sz - 1 doesn't work, does it? If it
does work, then better naming might help. I'm probably missing a really
obvious math trick here.
thanks,
--
John Hubbard
NVIDIA
+ refs = record_subpages(page,
m and progress them independently.
.. and I was just talking about this with Daniel Jordan and some other
people at your company :)
Thanks,
Jason
thanks,
--
John Hubbard
NVIDIA
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe sen
which approach is better because I haven't yet attempted to
find the common elements in these routines. But if there is *any way* to
avoid this copy-paste creation of yet more following of pages, then it's
*very* good to do.
thanks,
--
John Hubbard
NVIDIA
---
include/linux/huge_mm.h | 4 +
inc
sizeof(struct page *)),
+ PAGES_PER_LIST),
gup_flags | FOLL_LONGTERM, page_list);
if (ret < 0)
goto umem_release;
thanks,
--
John Hubbard
NVIDIA
ct zone *zone,
}
}
+ if (compound) {
+ for (pfn = start_pfn; pfn < end_pfn; pfn += align)
+ prep_compound_page(pfn_to_page(pfn),
order_base_2(align));
+ }
+
pr_info("%s initialised %lu pages in %ums
I didn't spot any other issues, though.
thanks,
--
John Hubbard
NVIDIA
+ altmap = ctx->altmap;
+
if (vmemmap_populate(start, end, nid, altmap))
return NULL;
diff --git a/mm/sparse.c b/mm/sparse.c
index 7bd23f9d6cef..47ca494398a7 100644
--- a/mm/spars
up.c | 103 +--
1 file changed, 23 insertions(+), 80 deletions(-)
Reviewed-by: John Hubbard
With a couple of minor notes below:
With Matt's folio idea I'd next to go to make a
put_folio(folio, refs)
Which would cleanly eliminate that extra atomic here without duplicating
y! Just these:
bool vma_is_secretmem(struct vm_area_struct *vma);
bool page_is_secretmem(struct page *page);
bool secretmem_active(void);
...or am I just Doing It Wrong? :)
thanks,
--
John Hubbard
NVIDIA
___
Linux-nvdimm mailing list -- linux
should be enough. There is no counter for page dirtiness,
and this kind of accounting is always tracked in the head page, so there
is no reason to repeatedly call set_page_dirty() from the same
spot.
thanks,
--
John Hubbard
NVIDIA
___
Linux-nvdimm mailin
40 matches
Mail list logo
