On Mon, 15 Aug 2016 04:51:59 PM Alistair Popple wrote:
> POWER9 contains an off core mmu called the nest mmu (NMMU). This is
> used by other hardware units on the chip to translate virtual
> addresses into real addresses. The unit attempting an address
> translation provides the maj
Hi,
We have been intermittently seeing the below RCU stall at boot on a PPC64LE
4.2.1 kernel which has been preventing the system from booting. Further
investigation indicates that ops->cur_blink_jiffies is potentially being used
uninitialised in cursor_timer_handler():
static void cursor_tim
On Sunday, 17 June 2018 11:22:11 AM AEST Benjamin Herrenschmidt wrote:
> On Sun, 2018-06-17 at 11:17 +1000, Benjamin Herrenschmidt wrote:
> >
> > We have everything that cronus needs and more than pdbg needs afaik :-)
Yep, has what we need and more (such as put scom under mask and indirect scom).
On Monday, 18 June 2018 2:46:33 PM AEST Benjamin Herrenschmidt wrote:
> On Mon, 2018-06-18 at 14:09 +1000, Alistair Popple wrote:
> > On Sunday, 17 June 2018 11:22:11 AM AEST Benjamin Herrenschmidt wrote:
> > > On Sun, 2018-06-17 at 11:17 +1000, Benjamin Herrenschmidt wrote:
&
Thanks for this Huang, I had been hoping to take a look at it this week
but have run out of time. I'm keen to do some testing with it as well.
Hopefully next week...
Huang Ying writes:
> We have the explicit memory tiers framework to manage systems with
> multiple types of memory, e.g., DRAM
of
> algorithm implementations can be specified via
> priority (notifier_block.priority).
How/what decides the priority though? That seems like something better
decided by a device driver than the algorithm driver IMHO.
> Signed-off-by: "Huang, Ying"
> Cc: Aneesh Kumar K.V
&g
refactor looks good and I have run the whole series on a system with
some hmat data so:
Reviewed-by: Alistair Popple
Tested-by: Alistair Popple
> Signed-off-by: "Huang, Ying"
> Cc: Aneesh Kumar K.V
> Cc: Wei Xu
> Cc: Alistair Popple
> Cc: Dan Williams
> Cc: Dave
rate/complete.
> Signed-off-by: "Huang, Ying"
> Cc: Aneesh Kumar K.V
> Cc: Wei Xu
> Cc: Alistair Popple
> Cc: Dan Williams
> Cc: Dave Hansen
> Cc: Davidlohr Bueso
> Cc: Johannes Weiner
> Cc: Jonathan Cameron
> Cc: Michal Hocko
>
ut into the "kmem_memory_types" list and protected by
> kmem_memory_type_lock.
See below but I wonder if kmem_memory_types could be a common helper
rather than kdax specific?
> Signed-off-by: "Huang, Ying"
> Cc: Aneesh Kumar K.V
> Cc: Wei Xu
> Cc: Alistair Pop
"Huang, Ying" writes:
> Hi, Alistair,
>
> Thanks a lot for comments!
>
> Alistair Popple writes:
>
>> Huang Ying writes:
>>
>>> The abstract distance may be calculated by various drivers, such as
>>> ACPI HMAT, CXL CDAT, etc. Whi
"Huang, Ying" writes:
>>> The other way (suggested by this series) is to make dax/kmem call a
>>> notifier chain, then CXL CDAT or ACPI HMAT can identify the type of
>>> device and calculate the distance if the type is correct for them. I
>>> don't think that it's good to make dax/kem to know
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> "Huang, Ying" writes:
>>
>>>>> And, I don't think that we are forced to use the general notifier
>>>>> chain interface in all memory device drivers. If the memory
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> "Huang, Ying" writes:
>>
>>> Alistair Popple writes:
>>>
>>>>>>> While other memory device drivers can use the general notifier chain
>>>>>&
"Huang, Ying" writes:
> Hi, Alistair,
>
> Sorry for late response. Just come back from vacation.
Ditto for this response :-)
I see Andrew has taken this into mm-unstable though, so my bad for not
getting around to following all this up sooner.
> Alistair Popple wri
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> Huang Ying writes:
>>
>>> A memory tiering abstract distance calculation algorithm based on ACPI
>>> HMAT is implemented. The basic idea is as follows.
>>>
>>> The perform
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> Huang Ying writes:
>>
>>> Previously, a fixed abstract distance MEMTIER_DEFAULT_DAX_ADISTANCE is
>>> used for slow memory type in kmem driver. This limits the usage of
>>> km
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> "Huang, Ying" writes:
>>
>>> Hi, Alistair,
>>>
>>> Sorry for late response. Just come back from vacation.
>>
>> Ditto for this response :-)
>>
>> I
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> "Huang, Ying" writes:
>>
>>> Alistair Popple writes:
>>>
>>>> "Huang, Ying" writes:
>>>>
>>>>> Hi, Alistair,
>>>>>
&g
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> "Huang, Ying" writes:
>>
>>> Alistair Popple writes:
>>>
>>>> Huang Ying writes:
>>>>
>>>>> Previously, a fixed abstract distance MEMTIER_DEF
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> "Huang, Ying" writes:
>>
>>> Alistair Popple writes:
>>>
>>>> "Huang, Ying" writes:
>>>>
>>>>> Alistair Popple writes:
>>>
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> "Huang, Ying" writes:
>>
>>> Alistair Popple writes:
>>>
>>>> "Huang, Ying" writes:
>>>>
>>>>> Alistair Popple writes:
>>&g
et_pte_at was
> > called later).
Thanks for the fixup. I didn't realise that invalidate_range() always gets
called but I now see that is the case so this change looks good to me as well.
Reviewed-by: Alistair Popple
> > All the necessary cache invalidation should all be
On Wednesday, 10 February 2021 12:39:32 AM AEDT Jason Gunthorpe wrote:
> On Tue, Feb 09, 2021 at 12:07:14PM +1100, Alistair Popple wrote:
> > Device private pages are used to represent device memory that is not
> > directly accessible from the CPU. Extra references to a device priva
On Thursday, 11 February 2021 6:55:10 PM AEDT Christoph Hellwig wrote:
> On Wed, Feb 10, 2021 at 01:59:13PM -0400, Jason Gunthorpe wrote:
> > Really what you want to do here is leave the CPU page in the VMA and
> > the page tables where it started and deny CPU access to the page. Then
> > all the p
.
Alistair Popple (4):
hmm: Device exclusive memory access
hmm: Selftests for exclusive device memory
nouveau/svm: Refactor nouveau_range_fault
nouveau/svm: Implement atomic SVM access
Documentation/vm/hmm.rst | 15 ++
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1
Adds some selftests for exclusive device memory.
Signed-off-by: Alistair Popple
---
lib/test_hmm.c | 124 ++
lib/test_hmm_uapi.h| 2 +
tools/testing/selftests/vm/hmm-tests.c | 219 +
3 files changed, 345
to proceed.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 +
drivers/gpu/drm/nouveau/nouveau_svm.c | 86 ---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 +
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 6 ++
4 files
Call mmu_interval_notifier_insert() as part of nouveau_range_fault().
This doesn't introduce any functional change but makes it easier for a
subsequent patch to alter the behaviour of nouveau_range_fault() to
support GPU atomic operations.
Signed-off-by: Alistair Popple
---
drivers/gp
original
mapping. This results in MMU notifiers being called which a driver uses
to update access permissions such as revoking atomic access. After
notifiers have been called the device will no longer have exclusive
access to the region.
Signed-off-by: Alistair Popple
---
Documentation/vm/hmm.rst
R on linus/master v5.11 next-20210218]
> [cannot apply to hnaz-linux-mm/master]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> ur
moved has yet to be resolved so any discussion is
welcome.
Alistair Popple (9):
mm/migrate.c: Always allow device private pages to migrate
mm/migrate.c: Allow pfn flags to be passed to migrate_vma_setup()
mm/migrate: Add a unmap and pin migration mode
Documentation: Add unmap and pin to
private page migration as this can lead to failures to
migrate pages back to the CPU which are fatal to the user process.
Signed-off-by: Alistair Popple
---
mm/migrate.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/mm/migrate.c b/mm/migrate.c
index 20ca887ea769
freed it is safe to allow the unmap
and pin operation to proceed in cases where there are extra page
references present.
Signed-off-by: Alistair Popple
---
include/linux/migrate.h | 2 +
include/linux/migrate_mode.h | 1 +
mm/migrate.c | 74
Update the HMM documentation to include information on the unmap and pin
operation.
Signed-off-by: Alistair Popple
---
Documentation/vm/hmm.rst | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index
pfn arrays.
Signed-off-by: Alistair Popple
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 4 ++--
lib/test_hmm.c | 6 --
mm/migrate.c | 1 -
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c
b/arch/powerpc/kvm
Adds a basic test of the HMM unmap and pin operation.
Signed-off-by: Alistair Popple
---
lib/test_hmm.c | 107 +
lib/test_hmm_uapi.h| 1 +
tools/testing/selftests/vm/hmm-tests.c | 49 +++
3 files changed, 140
uired.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 92987daa5e17..9579bd001f11 100644
--- a/drivers/gp
Call mmu_interval_notifier_insert() as part of nouveau_range_fault().
This doesn't introduce any functional change but makes it easier for a
subsequent patch to alter the behaviour of nouveau_range_fault() to
support GPU atomic operations.
Signed-off-by: Alistair Popple
---
drivers/gp
when accessing some GPU pages.
This patch extends the existing Nouveau device private page allocator to
make it easier to allocate device private pages with different callbacks
but should not introduce any functional changes.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouveau
: Alistair Popple
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 +
drivers/gpu/drm/nouveau/nouveau_dmem.c| 148 --
drivers/gpu/drm/nouveau/nouveau_dmem.h| 4 +
drivers/gpu/drm/nouveau/nouveau_svm.c | 116 --
drivers/gpu/drm/nouveau/nvkm
ssible to
add a callback in the page migration logic to specially deal with moving these
pages?
Thanks, Alistair
> Cheers, Daniel
>
>
>
> >
> > Alistair Popple (9):
> > mm/migrate.c: Always allow device private pages to migrate
> > mm/migrate.c: Allow pfn
stead of device
private pages.
Alistair Popple (8):
mm: Remove special swap entry functions
mm/swapops: Rework swap entry manipulation code
mm/rmap: Split try_to_munlock from try_to_unmap
mm/rmap: Split migration into its own function
mm: Device exclusive memory access
mm: Selftests for e
-off-by: Alistair Popple
---
include/linux/swapops.h | 56 ++---
mm/debug_vm_pgtable.c | 12 -
mm/hmm.c| 2 +-
mm/huge_memory.c| 26 +--
mm/hugetlb.c| 10 +---
mm/memory.c | 10
rather than
overload try_to_unmap_one() with unrelated behaviour split this out into
it's own function and remove the flag.
Signed-off-by: Alistair Popple
---
Given the comments on not needing to hold mmap_lock it was not 100% clear
to me if it is safe to check vma->vma_flags & VM_LOCK
Remove the migration and device private entry_to_page() and
entry_to_pfn() inline functions and instead open code them directly.
This results in shorter code which is easier to understand.
Signed-off-by: Alistair Popple
---
arch/s390/mm/pgtable.c | 2 +-
fs/proc/task_mmu.c | 23
try_to_migrate() for PageAnon or try_to_unmap().
Signed-off-by: Alistair Popple
---
include/linux/rmap.h | 4 +-
mm/huge_memory.c | 10 +-
mm/migrate.c | 9 +-
mm/rmap.c| 352 +++
4 files changed, 269 insertions(+), 106
Adds some selftests for exclusive device memory.
Signed-off-by: Alistair Popple
---
lib/test_hmm.c | 124 ++
lib/test_hmm_uapi.h| 2 +
tools/testing/selftests/vm/hmm-tests.c | 219 +
3 files changed, 345
Call mmu_interval_notifier_insert() as part of nouveau_range_fault().
This doesn't introduce any functional change but makes it easier for a
subsequent patch to alter the behaviour of nouveau_range_fault() to
support GPU atomic operations.
Signed-off-by: Alistair Popple
---
drivers/gp
original
mapping. This results in MMU notifiers being called which a driver uses
to update access permissions such as revoking atomic access. After
notifiers have been called the device will no longer have exclusive
access to the region.
Signed-off-by: Alistair Popple
---
Documentation/vm/hmm.rst
to proceed.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 +
drivers/gpu/drm/nouveau/nouveau_svm.c | 88 ---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 +
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 6 ++
4 files
On Tuesday, 23 March 2021 9:26:43 PM AEDT David Hildenbrand wrote:
> On 20.03.21 10:36, Miaohe Lin wrote:
> > If the zone device page does not belong to un-addressable device memory,
> > the variable entry will be uninitialized and lead to indeterminate pte
> > entry ultimately. Fix this unexpectan
On Wednesday, 3 March 2021 9:08:15 AM AEDT Zi Yan wrote:
> On 26 Feb 2021, at 2:18, Alistair Popple wrote:
> > diff --git a/include/linux/rmap.h b/include/linux/rmap.h
> > index 7f1ee411bd7b..77fa17de51d7 100644
> > --- a/include/linux/rmap.h
> > +++ b/include/linu
On Wednesday, 31 March 2021 5:49:03 AM AEDT Jason Gunthorpe wrote:
> On Fri, Mar 26, 2021 at 11:08:00AM +1100, Alistair Popple wrote:
>
> > +static bool try_to_munlock_one(struct page *page, struct vm_area_struct
*vma,
> > +unsigned long address, void *arg)
&
On Wednesday, 31 March 2021 9:09:30 AM AEDT Alistair Popple wrote:
> On Wednesday, 31 March 2021 5:49:03 AM AEDT Jason Gunthorpe wrote:
> > On Fri, Mar 26, 2021 at 11:08:00AM +1100, Alistair Popple wrote:
> > So what clears PG_mlocked on this call path?
>
> See munloc
On Wednesday, 31 March 2021 9:43:19 AM AEDT John Hubbard wrote:
> On 3/30/21 3:24 PM, Jason Gunthorpe wrote:
> ...
> >> As far as I can tell this has always been called try_to_munlock() even
though
> >> it appears to do the opposite.
> >
> > Maybe we should change it then?
> >
> >>> /**
> >>>
On Wednesday, 31 March 2021 2:56:38 PM AEDT John Hubbard wrote:
> On 3/30/21 3:56 PM, Alistair Popple wrote:
> ...
> >> +1 for renaming "munlock*" items to "mlock*", where applicable. good
grief.
> >
> > At least the situation was weird enough to pr
On Tuesday, 30 March 2021 8:13:32 PM AEDT David Hildenbrand wrote:
> External email: Use caution opening links or attachments
>
>
> On 29.03.21 03:37, Alistair Popple wrote:
> > On Friday, 26 March 2021 7:57:51 PM AEDT David Hildenbrand wrote:
> >> On 26.03.21 0
On Wednesday, 31 March 2021 6:32:34 AM AEDT Jason Gunthorpe wrote:
> On Fri, Mar 26, 2021 at 11:08:02AM +1100, Alistair Popple wrote:
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 3a5705cfc891..33d11527ef77 100644
> > +++ b/mm/memory.c
> > @@ -781,6 +781,27 @@
On Thursday, 1 April 2021 12:18:54 AM AEDT Jason Gunthorpe wrote:
> On Wed, Mar 31, 2021 at 11:59:28PM +1100, Alistair Popple wrote:
>
> > I guess that makes sense as the split could go either way at the
> > moment but I should add a check to make sure this isn't used with
On Tuesday, 2 March 2021 3:10:49 AM AEDT Jason Gunthorpe wrote:
> > + while (page_vma_mapped_walk(&pvmw)) {
> > + /*
> > +* If the page is mlock()d, we cannot swap it out.
> > +* If it's recently referenced (perhaps page_referenced
> > +
On Tuesday, 2 March 2021 11:41:52 PM AEDT Jason Gunthorpe wrote:
> > However try_to_protect() scans the PTEs again under the PTL so checking
the
> > mapping of interest actually gets replaced during the rmap walk seems like
a
> > reasonable solution. Thanks for the comments.
>
> It does seem c
g device page tables.
v3:
* Refactored some existing functionality.
* Switched to using get_user_pages_remote() instead of open-coding it.
* Moved code out of hmm.
v2:
* Changed implementation to use special swap entries instead of device
private pages.
Alistair Popple (8):
mm: Remove special sw
Remove the migration and device private entry_to_page() and
entry_to_pfn() inline functions and instead open code them directly.
This results in shorter code which is easier to understand.
Signed-off-by: Alistair Popple
---
v4:
* Added pfn_swap_entry_to_page()
* Reinstated check that migration
rather than
overload try_to_unmap_one() with unrelated behaviour split this out into
it's own function and remove the flag.
Signed-off-by: Alistair Popple
---
Christoph - I didn't add your Reviewed-by because removal of the extra
VM_LOCKED check changed things slightly. Let me know if you&#
try_to_migrate() for PageAnon or try_to_unmap().
Signed-off-by: Alistair Popple
Reviewed-by: Christoph Hellwig
---
include/linux/rmap.h | 4 +-
mm/huge_memory.c | 10 +-
mm/migrate.c | 9 +-
mm/rmap.c| 352 +++
4 files changed
original
mapping. This results in MMU notifiers being called which a driver uses
to update access permissions such as revoking atomic access. After
notifiers have been called the device will no longer have exclusive
access to the region.
Signed-off-by: Alistair Popple
---
v4:
* Add function to check
to proceed.
Signed-off-by: Alistair Popple
---
v4:
* Check that page table entries haven't changed before mapping on the
device
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 +
drivers/gpu/drm/nouveau/nouveau_svm.c | 107 --
drivers/gpu/drm/nouveau
Adds some selftests for exclusive device memory.
Signed-off-by: Alistair Popple
Acked-by: Jason Gunthorpe
Tested-by: Ralph Campbell
Reviewed-by: Ralph Campbell
---
lib/test_hmm.c | 124 ++
lib/test_hmm_uapi.h| 2 +
tools/testing
-by: Alistair Popple
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
include/linux/swapops.h | 56 ++---
mm/debug_vm_pgtable.c | 12 -
mm/hmm.c| 2 +-
mm/huge_memory.c| 26 +--
mm/hugetlb.c
Call mmu_interval_notifier_insert() as part of nouveau_range_fault().
This doesn't introduce any functional change but makes it easier for a
subsequent patch to alter the behaviour of nouveau_range_fault() to
support GPU atomic operations.
Signed-off-by: Alistair Popple
---
drivers/gp
On Monday, 15 March 2021 6:27:57 PM AEDT Christoph Hellwig wrote:
> On Fri, Mar 12, 2021 at 07:38:44PM +1100, Alistair Popple wrote:
> > Remove the migration and device private entry_to_page() and
> > entry_to_pfn() inline functions and instead open code them directly.
> > Th
On Monday, 15 March 2021 6:51:13 PM AEDT Christoph Hellwig wrote:
> > - /*XXX: atomic? */
> > - return (fa->access == 0 || fa->access == 3) -
> > - (fb->access == 0 || fb->access == 3);
> > + /* Atomic access (2) has highest priority */
> > + return (-1*(fa->access == 2) + (fa->acc
On Monday, 15 March 2021 6:42:45 PM AEDT Christoph Hellwig wrote:
> > +Not all devices support atomic access to system memory. To support atomic
> > +operations to a shared virtual memory page such a device needs access to
that
> > +page which is exclusive of any userspace access from the CPU. The
gt; https://github.com/0day-ci/linux/commits/Alistair-Popple/kernel-resource-Fix-locking-in-request_free_mem_region/20210326-092150
> base: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
a74e6a014c9d4d4161061f770c9b4f98372ac778
>
> in testcase: boot
>
> on test machine:
st_free_mem_region variant")
Fixes: 0092908d16c60 ("mm: factor out a devm_request_free_mem_region helper")
Fixes: 4ef589dc9b10c ("mm/hmm/devmem: device memory hotplug using ZONE_DEVICE")
Signed-off-by: Alistair Popple
Acked-by: Balbir Singh
Reported-by: kernel test robot
---
On Tuesday, 30 March 2021 2:42:34 PM AEDT John Hubbard wrote:
> On 3/29/21 5:38 PM, Alistair Popple wrote:
> > request_free_mem_region() is used to find an empty range of physical
> > addresses for hotplugging ZONE_DEVICE memory. It does this by iterating
> > over the range
rather than
overload try_to_unmap_one() with unrelated behaviour split this out into
it's own function and remove the flag.
Signed-off-by: Alistair Popple
Reviewed-by: Ralph Campbell
Reviewed-by: Christoph Hellwig
---
v7:
* Added Christoph's Reviewed-by
v4:
* Removed redundant check for
upstream Mesa userspace with a simple
OpenCL test program which checks the results of atomic GPU operations on a
SVM buffer whilst also writing to the same buffer from the CPU.
Alistair Popple (8):
mm: Remove special swap entry functions
mm/swapops: Rework swap entry manipulation code
mm/rma
original
mapping. This results in MMU notifiers being called which a driver uses
to update access permissions such as revoking atomic access. After
notifiers have been called the device will no longer have exclusive
access to the region.
Signed-off-by: Alistair Popple
Reviewed-by: Christoph Hellwig
pfn_swap_entry_to_page(). Also open-code the various entry_to_pfn()
functions as this results is shorter code that is easier to understand.
Signed-off-by: Alistair Popple
Reviewed-by: Ralph Campbell
Reviewed-by: Christoph Hellwig
---
v7:
* Reworded commit message to include pfn_swap_entry_to_page
-by: Alistair Popple
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
---
include/linux/swapops.h | 56 ++---
mm/debug_vm_pgtable.c | 12 -
mm/hmm.c| 2 +-
mm/huge_memory.c| 26
Call mmu_interval_notifier_insert() as part of nouveau_range_fault().
This doesn't introduce any functional change but makes it easier for a
subsequent patch to alter the behaviour of nouveau_range_fault() to
support GPU atomic operations.
Signed-off-by: Alistair Popple
---
drivers/gp
try_to_migrate() for PageAnon or try_to_unmap().
Signed-off-by: Alistair Popple
Reviewed-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
v5:
* Added comments about how PMD splitting works for migration vs.
unmapping
* Tightened up the flag check in try_to_migrate() to be explicit about
Adds some selftests for exclusive device memory.
Signed-off-by: Alistair Popple
Acked-by: Jason Gunthorpe
Tested-by: Ralph Campbell
Reviewed-by: Ralph Campbell
---
lib/test_hmm.c | 124 +++
lib/test_hmm_uapi.h| 2 +
tools/testing
to proceed.
Signed-off-by: Alistair Popple
---
v7:
* Removed magic values for fault access levels
* Improved readability of fault comparison code
v4:
* Check that page table entries haven't changed before mapping on the
device
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h
be held over the required calls.
Instead of creating another version of devm_request_mem_region() that
doesn't take the lock open-code it to allow the caller to pre-allocate
the required memory prior to taking the lock.
Signed-off-by: Alistair Popple
---
ke
st_free_mem_region variant")
Fixes: 0092908d16c60 ("mm: factor out a devm_request_free_mem_region helper")
Fixes: 4ef589dc9b10c ("mm/hmm/devmem: device memory hotplug using ZONE_DEVICE")
Signed-off-by: Alistair Popple
---
v2:
- Added Fixes tag
---
kernel/resource.c | 146 +++
On Friday, 26 March 2021 7:57:51 PM AEDT David Hildenbrand wrote:
> On 26.03.21 02:20, Alistair Popple wrote:
> > request_free_mem_region() is used to find an empty range of physical
> > addresses for hotplugging ZONE_DEVICE memory. It does this by iterating
> > over
On Friday, 26 March 2021 4:15:36 PM AEDT Balbir Singh wrote:
> On Fri, Mar 26, 2021 at 12:20:35PM +1100, Alistair Popple wrote:
> > +static int __region_intersects(resource_size_t start, size_t size,
> > +unsigned long flags, unsigned long desc)
> >
alls resource code so cannot be called with the resource lock held.
Therefore call it only after dropping the lock.
Fixes: 4ef589dc9b10c ("mm/hmm/devmem: device memory hotplug using ZONE_DEVICE")
Signed-off-by: Alistair Popple
Acked-by: Balbir Singh
Reported-by: kernel test robot
---
Chang
original
mapping. This results in MMU notifiers being called which a driver uses
to update access permissions such as revoking atomic access. After
notifiers have been called the device will no longer have exclusive
access to the region.
Signed-off-by: Alistair Popple
Reviewed-by: Christoph Hellwig
pfn_swap_entry_to_page(). Also open-code the various entry_to_pfn()
functions as this results is shorter code that is easier to understand.
Signed-off-by: Alistair Popple
Reviewed-by: Ralph Campbell
Reviewed-by: Christoph Hellwig
---
v7:
* Reworded commit message to include pfn_swap_entry_to_page
to proceed.
Signed-off-by: Alistair Popple
---
v7:
* Removed magic values for fault access levels
* Improved readability of fault comparison code
v4:
* Check that page table entries haven't changed before mapping on the
device
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h
-by: Alistair Popple
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
---
include/linux/swapops.h | 56 ++---
mm/debug_vm_pgtable.c | 12 -
mm/hmm.c| 2 +-
mm/huge_memory.c| 26
ecks the results of atomic GPU operations on a
SVM buffer whilst also writing to the same buffer from the CPU.
Alistair Popple (8):
mm: Remove special swap entry functions
mm/swapops: Rework swap entry manipulation code
mm/rmap: Split try_to_munlock from try_to_unmap
mm/rmap: Split migration
try_to_migrate() for PageAnon or try_to_unmap().
Signed-off-by: Alistair Popple
Reviewed-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
v5:
* Added comments about how PMD splitting works for migration vs.
unmapping
* Tightened up the flag check in try_to_migrate() to be explicit about
Call mmu_interval_notifier_insert() as part of nouveau_range_fault().
This doesn't introduce any functional change but makes it easier for a
subsequent patch to alter the behaviour of nouveau_range_fault() to
support GPU atomic operations.
Signed-off-by: Alistair Popple
---
drivers/gp
Adds some selftests for exclusive device memory.
Signed-off-by: Alistair Popple
Acked-by: Jason Gunthorpe
Tested-by: Ralph Campbell
Reviewed-by: Ralph Campbell
---
lib/test_hmm.c | 124 +++
lib/test_hmm_uapi.h| 2 +
tools/testing
rather than
overload try_to_unmap_one() with unrelated behaviour split this out into
it's own function and remove the flag.
Signed-off-by: Alistair Popple
Reviewed-by: Ralph Campbell
Reviewed-by: Christoph Hellwig
---
v8:
* Renamed try_to_munlock to page_mlock to better reflect what the
fun
On Thursday, 1 April 2021 12:46:04 AM AEDT Jason Gunthorpe wrote:
> On Thu, Apr 01, 2021 at 12:27:52AM +1100, Alistair Popple wrote:
> > On Thursday, 1 April 2021 12:18:54 AM AEDT Jason Gunthorpe wrote:
> > > On Wed, Mar 31, 2021 at 11:59:28PM +1100, Alistair Popple wrote:
>
1 - 100 of 235 matches
Mail list logo
