Re: [PATCH 2/7] mm: Free device private pages have zero refcount

Alistair Popple wrote: > > Dan Williams writes: > > > Alistair Popple wrote: > >> > >> Jason Gunthorpe writes: > >> > >> > On Mon, Sep 26, 2022 at 04:03:06PM +1000, Alistair Popple wrote: > >> >> Since 27674ef6c73f (&q

Re: [PATCH 2/7] mm: Free device private pages have zero refcount

Alistair Popple wrote: > > Jason Gunthorpe writes: > > > On Mon, Sep 26, 2022 at 04:03:06PM +1000, Alistair Popple wrote: > >> Since 27674ef6c73f ("mm: remove the extra ZONE_DEVICE struct page > >> refcount") device private pages have no longer had an extra reference > >> count when the page is

Re: [PATCH 7/8] mm: remove the extra ZONE_DEVICE struct page refcount

ge cache. This looks ok to me, and passes my tests. So given I'm still working my way back to fixing the references properly I'm ok for this hack to replace the more broken hack that is there presently. Reviewed-by: Dan Williams

Re: [PATCH 6/8] mm: don't include in

On Mon, Feb 7, 2022 at 3:49 PM Dan Williams wrote: > > On Sun, Feb 6, 2022 at 10:33 PM Christoph Hellwig wrote: > > > > Move the check for the actual pgmap types that need the free at refcount > > one behavior into the out of line helper, and thus avoid the need to >

Re: [PATCH 6/8] mm: don't include in

e. Reviewed-by: Dan Williams > > Signed-off-by: Christoph Hellwig > --- > arch/arm64/mm/mmu.c| 1 + > drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 1 + > drivers/gpu/drm/drm_cache.c| 2 +- > drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 + > d

Re: [PATCH 5/8] mm: simplify freeing of devmap managed pages

On Sun, Feb 6, 2022 at 10:33 PM Christoph Hellwig wrote: > > Make put_devmap_managed_page return if it took charge of the page > or not and remove the separate page_is_devmap_managed helper. Looks good to me: Reviewed-by: Dan Williams

Re: [PATCH 4/8] mm: move free_devmap_managed_page to memremap.c

On Sun, Feb 6, 2022 at 10:33 PM Christoph Hellwig wrote: > > free_devmap_managed_page has nothing to do with the code in swap.c, > move it to live with the rest of the code for devmap handling. > Looks good. Reviewed-by: Dan Williams

Re: [PATCH 2/8] mm: remove the __KERNEL__ guard from

On Sun, Feb 6, 2022 at 10:33 PM Christoph Hellwig wrote: > > __KERNEL__ ifdefs don't make sense outside of include/uapi/. Yes. Reviewed-by: Dan Williams

Re: [PATCH 1/8] mm: remove a pointless CONFIG_ZONE_DEVICE check in memremap_pages

On Sun, Feb 6, 2022 at 10:33 PM Christoph Hellwig wrote: > > memremap.c is only built when CONFIG_ZONE_DEVICE is set, so remove > the superflous extra check. Looks good to me. Reviewed-by: Dan Williams

Re: [PATCH v1 2/2] mm: remove extra ZONE_DEVICE struct page refcount

On Wed, Oct 20, 2021 at 10:09 AM Joao Martins wrote: > > On 10/19/21 20:21, Dan Williams wrote: > > On Tue, Oct 19, 2021 at 9:02 AM Jason Gunthorpe wrote: > >> > >> On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote: > >>> On 10/19/21 00:06, Ja

Re: [PATCH v1 2/2] mm: remove extra ZONE_DEVICE struct page refcount

On Tue, Oct 19, 2021 at 9:02 AM Jason Gunthorpe wrote: > > On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote: > > On 10/19/21 00:06, Jason Gunthorpe wrote: > > > On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote: > > > > > >

Re: [PATCH v1 2/2] mm: remove extra ZONE_DEVICE struct page refcount

On Mon, Oct 18, 2021 at 11:26 AM Jason Gunthorpe wrote: > > On Sun, Oct 17, 2021 at 11:35:35AM -0700, Dan Williams wrote: > > > > DAX is stuffing arrays of 4k pages into the PUD/PMDs. Aligning with > > > THP would make using normal refconting much simpler. I looked at

Re: [PATCH v1 2/2] mm: remove extra ZONE_DEVICE struct page refcount

On Sat, Oct 16, 2021 at 8:45 AM Jason Gunthorpe wrote: > > On Thu, Oct 14, 2021 at 06:37:35PM -0700, Dan Williams wrote: > > On Thu, Oct 14, 2021 at 4:06 PM Jason Gunthorpe wrote: > > > > > > On Thu, Oct 14, 2021 at 12:01:14PM -0700, Dan Williams wrote: > >

Re: [PATCH v1 2/2] mm: remove extra ZONE_DEVICE struct page refcount

On Sat, Oct 16, 2021 at 9:39 AM Matthew Wilcox wrote: > > On Sat, Oct 16, 2021 at 12:44:50PM -0300, Jason Gunthorpe wrote: > > Assuming changing FSDAX is hard.. How would DAX people feel about just > > deleting the PUD/PMD support until it can be done with compound pages? > > I think there are

Re: [PATCH v1 2/2] mm: remove extra ZONE_DEVICE struct page refcount

On Thu, Oct 14, 2021 at 4:06 PM Jason Gunthorpe wrote: > > On Thu, Oct 14, 2021 at 12:01:14PM -0700, Dan Williams wrote: > > > > Does anyone know why devmap is pte_special anyhow? > > > > It does not need to be special as mentioned here: > > > > http

Re: [PATCH v1 2/2] mm: remove extra ZONE_DEVICE struct page refcount

On Thu, Oct 14, 2021 at 11:45 AM Matthew Wilcox wrote: > > > It would probably help if you cc'd Dan on this. Thanks. [..] > > On Thu, Oct 14, 2021 at 02:06:34PM -0300, Jason Gunthorpe wrote: > > On Thu, Oct 14, 2021 at 10:39:28AM -0500, Alex Sierra wrote: > > > From: Ralph Campbell > > > > > >

Re: [PATCH v1 03/14] mm: add iomem vma selection for memory migration

On Thu, Sep 2, 2021 at 1:18 AM Christoph Hellwig wrote: > > On Wed, Sep 01, 2021 at 11:40:43AM -0400, Felix Kuehling wrote: > > >>> It looks like I'm totally misunderstanding what you are adding here > > >>> then. Why do we need any special treatment at all for memory that > > >>> has normal

Re: [RFC] treewide: cleanup unreachable breaks

/claim.c > +++ b/drivers/nvdimm/claim.c > @@ -200,11 +200,10 @@ ssize_t nd_namespace_store(struct device *dev, > } > break; > default: > len = -EBUSY; > goto out_attach; > - break; > } Acked-by: Dan Williams ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()

On Fri, Oct 9, 2020 at 12:52 PM wrote: > > From: Ira Weiny > > 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. > > Cc: Nicolas Pitre > Signed-off-by: Ira Weiny > --- > fs/cramfs/inode.c | 10

Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()

On Tue, Oct 13, 2020 at 12:37 PM Matthew Wilcox wrote: > > On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote: > > On Fri, Oct 9, 2020 at 12:52 PM wrote: > > > > > > From: Ira Weiny > > > > > > The kmap() calls in this FS are localized t

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Fri, Aug 16, 2019 at 5:24 AM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 08:54:46PM -0700, Dan Williams wrote: > > > > However, this means we cannot do any processing of ZONE_DEVICE pages > > > outside the driver lock, so eg, doing

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Thu, Aug 15, 2019 at 5:41 PM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 01:47:12PM -0700, Dan Williams wrote: > > On Thu, Aug 15, 2019 at 1:41 PM Jason Gunthorpe wrote: > > > > > > On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote: >

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Thu, Aug 15, 2019 at 12:44 PM Jerome Glisse wrote: > > On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams wrote: > > On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse wrote: > > > > > > On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote: > >

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Thu, Aug 15, 2019 at 1:41 PM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote: > > > So nor HMM nor driver should dereference the struct page (i do not > > think any iommu driver would either), > > Er, they do technically deref the struct page: > >

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse wrote: > > On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote: > > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe wrote: > > > > > > On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig wrote: > &g

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe wrote: > > On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig wrote: > > On Tue, Aug 13, 2019 at 06:36:33PM -0700, Dan Williams wrote: > > > Section alignment constraints somewhat save us here. The only example >

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Wed, Aug 7, 2019 at 11:59 PM Christoph Hellwig wrote: > > On Wed, Aug 07, 2019 at 11:47:22AM -0700, Dan Williams wrote: > > > Unrelated to this patch, but what is the point of getting checking > > > that the pgmap exists for the page and then immediately releasing

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Wed, Aug 7, 2019 at 10:45 AM Jason Gunthorpe wrote: > > On Tue, Aug 06, 2019 at 07:05:42PM +0300, Christoph Hellwig wrote: > > There is only a single place where the pgmap is passed over a function > > call, so replace it with local variables in the places where we deal > > with the pgmap. > >

Re: [PATCH v5 13/29] compat_ioctl: move more drivers to compat_ptr_ioctl

dimm_ioctl, > - .compat_ioctl = dimm_ioctl, > + .compat_ioctl = compat_ptr_ioctl, > .llseek = noop_llseek, > }; Acked-by: Dan Williams ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 10:44 AM, Alex Deucher wrote: > On Wed, Apr 25, 2018 at 2:41 AM, Christoph Hellwig wrote: >> On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote: >>> > It has a non-coherent transaction mode (which the chipset can opt to