On 29.11.23 09:27, zhuweixi wrote:
Glad to hear that more sharable code is desirable.
IMHO, for a common MM subsystem, it is more beneficial for
GMEM to extend core MM instead of building a separate one.
More core-mm complexity, awesome, we all love that! ;)
--
Cheers,
David / dhildenb
On 01.12.23 03:44, zhuweixi wrote:
Thanks!
I hope you understood that that was a joke :)
I am planning to present GMEM in Linux MM Alignment Sessions so I can collect
more input from the mm developers.
Sounds good. But please try inviting key HMM/driver developer as well.
Most of the core
On 28.11.23 13:50, Weixi Zhu wrote:
This patch adds an abstraction layer, struct vm_object, that maintains
per-process virtual-to-physical mapping status stored in struct gm_mapping.
For example, a virtual page may be mapped to a CPU physical page or to a
device physical page. Struct vm_object ef
On 02.12.23 15:50, Pedro Falcato wrote:
On Fri, Dec 1, 2023 at 9:23 AM David Hildenbrand wrote:
On 28.11.23 13:50, Weixi Zhu wrote:
This patch adds an abstraction layer, struct vm_object, that maintains
per-process virtual-to-physical mapping status stored in struct gm_mapping.
For example
On 10.01.22 23:31, Alex Sierra wrote:
> This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
> owned by a device that can be mapped into CPU page tables like
> MEMORY_DEVICE_GENERIC and can also be migrated like
> MEMORY_DEVICE_PRIVATE.
>
> Christoph, the suggestion to incorporate
On 10.02.22 12:39, Alistair Popple wrote:
> On Thursday, 10 February 2022 9:53:38 PM AEDT David Hildenbrand wrote:
>> On 07.02.22 05:26, Alistair Popple wrote:
>>> Currently any attempts to pin a device coherent page will fail. This is
>>> because device coherent pa
On 07.02.22 05:26, Alistair Popple wrote:
> Currently any attempts to pin a device coherent page will fail. This is
> because device coherent pages need to be managed by a device driver, and
> pinning them would prevent a driver from migrating them off the device.
>
> However this is no reason to
On 01.02.22 16:48, Alex Sierra wrote:
> Device memory that is cache coherent from device and CPU point of view.
> This is used on platforms that have an advanced system bus (like CAPI
> or CXL). Any page of a process can be migrated to such memory. However,
> no one should be allowed to pin such me
On 11.02.22 17:15, David Hildenbrand wrote:
> On 01.02.22 16:48, Alex Sierra wrote:
>> Device memory that is cache coherent from device and CPU point of view.
>> This is used on platforms that have an advanced system bus (like CAPI
>> or CXL). Any page of a process can be mi
On 11.02.22 17:45, Jason Gunthorpe wrote:
> On Fri, Feb 11, 2022 at 05:15:25PM +0100, David Hildenbrand wrote:
>
>> ... I'm pretty sure we cannot FOLL_PIN DEVICE_PRIVATE pages
>
> Currently the only way to get a DEVICE_PRIVATE page out of the page
> tables is via
On 11.02.22 00:41, Alistair Popple wrote:
> On Thursday, 10 February 2022 10:47:35 PM AEDT David Hildenbrand wrote:
>> On 10.02.22 12:39, Alistair Popple wrote:
>>> On Thursday, 10 February 2022 9:53:38 PM AEDT David Hildenbrand wrote:
>>>> On 07.02.22 05:26, Alistair
On 11.02.22 17:56, Jason Gunthorpe wrote:
> On Fri, Feb 11, 2022 at 05:49:08PM +0100, David Hildenbrand wrote:
>> On 11.02.22 17:45, Jason Gunthorpe wrote:
>>> On Fri, Feb 11, 2022 at 05:15:25PM +0100, David Hildenbrand wrote:
>>>
>>>> ... I'm pretty
On 11.02.22 18:07, Felix Kuehling wrote:
>
> Am 2022-02-11 um 11:39 schrieb David Hildenbrand:
>> On 11.02.22 17:15, David Hildenbrand wrote:
>>> On 01.02.22 16:48, Alex Sierra wrote:
>>>> Device memory that is cache coherent from device and CPU point of view.
&g
On 11.03.21 15:41, Deucher, Alexander wrote:
[AMD Public Use]
Booting kernels on certain AMD platforms takes 2-3 minutes with the patch in
the subject. Reverting it restores quick boot times (few seconds). Any ideas?
Hi,
We just discovered latent BUGs in ACPI code whereby ACPI tables are
On 12.03.21 15:06, Deucher, Alexander wrote:
[AMD Public Use]
-Original Message-
From: David Hildenbrand
Sent: Thursday, March 11, 2021 10:03 AM
To: Deucher, Alexander ; linux-
ker...@vger.kernel.org; amd-gfx list ;
Andrew Morton
Cc: Huang, Ray ; Koenig, Christian
; Liang, Liang (Leo
8G (with some carve out for the integrated GPU).
[0.044181] Memory: 6858688K/7200304K available (14345K kernel code, 9659K
rwdata, 4980K rodata, 2484K init, 12292K bss, 341360K reserved, 0K cma-reserved)
Nothing particularly special about these systems that I am aware of. I'll see
if we ca
On 12.03.21 17:19, Liang, Liang (Leo) wrote:
[AMD Public Use]
Dmesg attached.
So, looks like the "real" slowdown starts once the buddy is up and running (no
surprise).
[0.044035] Memory: 6856724K/7200304K available (14345K kernel code, 9699K
rwdata, 5276K rodata, 2628K init, 12104K b
all 4MB pages in the
freelists and perform a stream benchmark individually. Then we might be able to
identify the problematic range - if there is a problematic range :) Guess I‘ll
have it running by Monday and let you know.
Cheers!
>
> BRs,
> Leo
> -----Original Message-
> From:
On 13.03.21 14:48, Mike Rapoport wrote:
Hi,
On Sat, Mar 13, 2021 at 10:05:23AM +0100, David Hildenbrand wrote:
Am 13.03.2021 um 05:04 schrieb Liang, Liang (Leo) :
Hi David,
Which benchmark tool you prefer? Memtest86+ or else?
Hi Leo,
I think you want something that runs under Linux
On 16.03.21 09:00, Liang, Liang (Leo) wrote:
[AMD Public Use]
Hi Mike,
Thanks for help. The patch works for me and boot time back to normal. So it's a
fix, or just WA?
Hi Leo,
excluding up to 16 MiB of memory on every system just because that
single platform is weird is not acceptable.
I
On 16.03.21 09:43, Liang, Liang (Leo) wrote:
[AMD Public Use]
Hi David,
Thanks for your explanation. We saw slow boot issue on our farm/QA's machines
and mine. All of machines are same SoC/board.
I cannot spot anything really special in the logs -- it's just ordinary
system ram -- except:
On 16.03.21 09:58, Liang, Liang (Leo) wrote:
[AMD Public Use]
Hi David,
root@scbu-Chachani:~# cat /proc/mtrr
reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back
reg01: base=0x0ffe0 ( 4094MB), size=2MB, count=1: write-protect
reg02: base=0x1 ( 4096MB), size= 16
On 16.03.21 12:02, Liang, Liang (Leo) wrote:
[AMD Public Use]
Hi David and Mike,
It's BIOS buggy. Now fixed by new BIOS. Thanks you so much! Cheers!
[0.34] MTRR variable ranges enabled:
[0.35] 0 base mask 8000 write-back
[0.37] 1 base FFE000
On 16.02.22 03:36, Alistair Popple wrote:
> On Wednesday, 16 February 2022 1:03:57 PM AEDT Jason Gunthorpe wrote:
>> On Wed, Feb 16, 2022 at 12:23:44PM +1100, Alistair Popple wrote:
>>
>>> Device private and device coherent pages are not marked with pte_devmap and
>>> they
>>> are backed by a stru
On 28.02.22 21:34, Alex Sierra wrote:
> DEVICE_COHERENT pages introduce a subtle distinction in the way
> "normal" pages can be used by various callers throughout the kernel.
> They behave like normal pages for purposes of mapping in CPU page
> tables, and for COW. But they do not support LRU lists
On 01.03.22 17:30, Felix Kuehling wrote:
> Am 2022-03-01 um 11:22 schrieb David Hildenbrand:
>>>>> if (PageReserved(page))
>>>>> diff --git a/mm/migrate.c b/mm/migrate.c
>>>>> index c31d04b46a5e..17d049311b78 100644
&
>>
>>> if (PageReserved(page))
>>> diff --git a/mm/migrate.c b/mm/migrate.c
>>> index c31d04b46a5e..17d049311b78 100644
>>> --- a/mm/migrate.c
>>> +++ b/mm/migrate.c
>>> @@ -1614,7 +1614,7 @@ static int add_page_for_migration(struct mm_struct
>>> *mm, unsigned long addr,
>>>
On 10.03.22 18:26, Alex Sierra wrote:
> DEVICE_COHERENT pages introduce a subtle distinction in the way
> "normal" pages can be used by various callers throughout the kernel.
> They behave like normal pages for purposes of mapping in CPU page
> tables, and for COW. But they do not support LRU lists
On 17.03.22 03:54, Alistair Popple wrote:
> Felix Kuehling writes:
>
>> On 2022-03-11 04:16, David Hildenbrand wrote:
>>> On 10.03.22 18:26, Alex Sierra wrote:
>>>> DEVICE_COHERENT pages introduce a subtle distinction in the way
>>>> "normal&qu
On 31.03.22 10:53, Christoph Hellwig wrote:
>> -page = vm_normal_page(vma, addr, pte);
>> +page = vm_normal_lru_page(vma, addr, pte);
>
> Why can't this deal with ZONE_DEVICE pages? It certainly has
> nothing do with a LRU I think. In fact being able to have
> stats that count say the nu
On 23.06.22 20:20, Sierra Guiza, Alejandro (Alex) wrote:
>
> On 6/23/2022 2:57 AM, David Hildenbrand wrote:
>> On 23.06.22 01:16, Sierra Guiza, Alejandro (Alex) wrote:
>>> On 6/21/2022 11:16 AM, David Hildenbrand wrote:
>>>> On 21.06.22 18:08, Sierra Guiza, Alej
On 28.06.22 02:14, Alex Sierra wrote:
> is_device_coherent checker was added to is_pinnable_page and renamed
> to is_longterm_pinnable_page. The reason is that device coherent
> pages are not supported for longterm pinning.
>
> Signed-off-by: Alex Sierra
> ---
> include/linux/memremap.h | 25 +++
On 28.06.22 02:14, Alex Sierra wrote:
> With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
> device-managed anonymous pages that are not LRU pages. Although they
> behave like normal pages for purposes of mapping in CPU page, and for
> COW. They do not support LRU lists, NUMA migration
On 29.06.22 05:54, Alex Sierra wrote:
> is_pinnable_page() and folio_is_pinnable() were renamed to
> is_longterm_pinnable_page() and folio_is_longterm_pinnable()
> respectively. These functions are used in the FOLL_LONGTERM flag
> context.
Subject talks about "*_pages"
Can you elaborate why the
continue;
>
> /* Also skip shared copy-on-write pages */
In -next/-mm there is now an additional can_change_pte_writable() that
calls vm_normal_page() -- added by me. I assume that that is indeed
fine because we can simply map device coherent pages writable.
Besides the nits, LGTM
Acked-by: David Hildenbrand
--
Thanks,
David / dhildenb
ellwig
>From what I can tell, this looks good to me
Acked-by: David Hildenbrand
--
Thanks,
David / dhildenb
On 30.06.22 00:08, Felix Kuehling wrote:
> On 2022-06-29 03:33, David Hildenbrand wrote:
>> On 29.06.22 05:54, Alex Sierra wrote:
>>> is_pinnable_page() and folio_is_pinnable() were renamed to
>>> is_longterm_pinnable_page() and folio_is_longterm_pinnable()
>>&g
On 29.06.22 05:54, Alex Sierra wrote:
> This case is used to migrate pages from device memory, back to system
> memory. Device coherent type memory is cache coherent from device and CPU
> point of view.
>
> Signed-off-by: Alex Sierra
> Acked-by: Felix Kuehling
> Reviewed-by: Alistair Poppple
>
On 30.06.22 13:44, Alistair Popple wrote:
>
> David Hildenbrand writes:
>
>> On 29.06.22 05:54, Alex Sierra wrote:
>>> This case is used to migrate pages from device memory, back to system
>>> memory. Device coherent type memory is cache coherent from
---
> include/linux/mm.h | 8
> mm/gup.c | 4 ++--
> mm/gup_test.c | 2 +-
> mm/hugetlb.c | 2 +-
> 4 files changed, 8 insertions(+), 8 deletions(-)
>
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
On 07.07.22 21:03, Alex Sierra wrote:
> [WHY]
> Have a cleaner way to expose all page zone helpers in one header
What exactly is a "page zone"? Do you mean a buddy zone as in
include/linux/mmzone.h ?
--
Thanks,
David / dhildenb
On 07.07.22 21:03, Alex Sierra wrote:
> From: Alistair Popple
>
> Currently any attempts to pin a device coherent page will fail. This is
> because device coherent pages need to be managed by a device driver, and
> pinning them would prevent a driver from migrating them off the device.
>
> Howev
On 07.07.22 21:03, Alex Sierra wrote:
> From: Alistair Popple
>
> migrate_vma_setup() checks that a valid vma is passed so that the page
> tables can be walked to find the pfns associated with a given address
> range. However in some cases the pfns are already known, such as when
> migrating devi
On 08.07.22 23:25, Felix Kuehling wrote:
> On 2022-07-08 07:28, David Hildenbrand wrote:
>> On 07.07.22 21:03, Alex Sierra wrote:
>>> [WHY]
>>> Have a cleaner way to expose all page zone helpers in one header
>> What exactly is a "page zone"? Do y
On 11.07.22 16:00, Matthew Wilcox wrote:
> On Mon, Jul 11, 2022 at 03:35:42PM +0200, David Hildenbrand wrote:
>>> + /*
>>> +* Device coherent pages are managed by a driver and should not
>>> +* be pinned indefinitely as it
On 15.07.22 17:05, Alex Sierra wrote:
> [WHY]
> It makes more sense to have these helpers in zone specific header
> file, rather than the generic mm.h
>
> Signed-off-by: Alex Sierra
Acked-by: David Hildenbrand
--
Thanks,
David / dhildenb
; Acked-by: Felix Kuehling (v2)
> Reviewed-by: Alistair Popple (v6)
>
Acked-by: David Hildenbrand
--
Thanks,
David / dhildenb
_error_count)
> + if (!list_empty(&movable_page_list) || isolation_error_count
> + || coherent_pages)
The common style is to
a) add the || to the end of the previous line
b) indent such the we have a nice-to-read alignment
if (!list_empty(&movable_page_list) || isol
On 18.07.22 19:52, Felix Kuehling wrote:
> On 2022-07-18 06:50, David Hildenbrand wrote:
>> On 15.07.22 17:05, Alex Sierra wrote:
>>> [WHY]
>>> It makes more sense to have these helpers in zone specific header
>>> file, rather than the generic mm.h
>>>
On 18.07.22 22:32, Andrew Morton wrote:
> On Mon, 18 Jul 2022 12:56:29 +0200 David Hildenbrand wrote:
>
>>> /*
>>> * Try to move out any movable page before pinning the range.
>>> */
>>> @@ -1919,7 +1948,8 @@ s
On 21.07.22 04:05, Alistair Popple wrote:
> Commit b05a79d4377f ("mm/gup: migrate device coherent pages when pinning
> instead of failing") added a badly formatted if statement. Fix it.
>
> Signed-off-by: Alistair Popple
> Reported-by: David Hildenbrand
> ---
>
part of a patch series aiming to remove the vmas parameter
altogether.
Signed-off-by: Lorenzo Stoakes
Suggested-by: Matthew Wilcox (Oracle)
Acked-by: Greg Kroah-Hartman
---
Acked-by: David Hildenbrand
--
Thanks,
David / dhildenb
the actions
implied by the input flags.
This is part of a patch series aiming to remove the vmas parameter
altogether.
Suggested-by: Matthew Wilcox (Oracle)
Acked-by: Greg Kroah-Hartman
Acked-by: David Hildenbrand
Reviewed-by: Jason Gunthorpe
Acked-by: Christian K�nig (for radeon parts
On 16.05.23 16:30, Sean Christopherson wrote:
On Tue, May 16, 2023, David Hildenbrand wrote:
On 15.05.23 21:07, Sean Christopherson wrote:
On Sun, May 14, 2023, Lorenzo Stoakes wrote:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index cb5c13eee193..eaa5bb8dbadc 100644
--- a/virt/kvm
On 17.06.22 04:19, Andrew Morton wrote:
> On Tue, 31 May 2022 15:00:28 -0500 Alex Sierra wrote:
>
>> This is our MEMORY_DEVICE_COHERENT patch series rebased and updated
>> for current 5.18.0
>
> I plan to move this series into the non-rebasing mm-stable branch in a
> few days. Unless sternly to
On 31.05.22 22:00, Alex Sierra wrote:
> With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
> device-managed anonymous pages that are not LRU pages. Although they
> behave like normal pages for purposes of mapping in CPU page, and for
> COW. They do not support LRU lists, NUMA migration
On 31.05.22 22:00, Alex Sierra wrote:
> Device memory that is cache coherent from device and CPU point of view.
> This is used on platforms that have an advanced system bus (like CAPI
> or CXL). Any page of a process can be migrated to such memory. However,
> no one should be allowed to pin such me
On 17.06.22 19:20, Sierra Guiza, Alejandro (Alex) wrote:
>
> On 6/17/2022 4:40 AM, David Hildenbrand wrote:
>> On 31.05.22 22:00, Alex Sierra wrote:
>>> Device memory that is cache coherent from device and CPU point of view.
>>> This is used on platforms that hav
On 17.06.22 21:27, Sierra Guiza, Alejandro (Alex) wrote:
>
> On 6/17/2022 12:33 PM, David Hildenbrand wrote:
>> On 17.06.22 19:20, Sierra Guiza, Alejandro (Alex) wrote:
>>> On 6/17/2022 4:40 AM, David Hildenbrand wrote:
>>>> On 31.05.22 22:00, Alex Sierra wrote:
On 21.06.22 13:25, Felix Kuehling wrote:
>
> Am 6/17/22 um 23:19 schrieb David Hildenbrand:
>> On 17.06.22 21:27, Sierra Guiza, Alejandro (Alex) wrote:
>>> On 6/17/2022 12:33 PM, David Hildenbrand wrote:
>>>> On 17.06.22 19:20, Sierra Guiza, Alejandro (Alex)
On 21.06.22 13:55, Alistair Popple wrote:
>
> David Hildenbrand writes:
>
>> On 21.06.22 13:25, Felix Kuehling wrote:
>>>
>>> Am 6/17/22 um 23:19 schrieb David Hildenbrand:
>>>> On 17.06.22 21:27, Sierra Guiza, Alejandro (Alex) wrote:
>>
On 21.06.22 18:08, Sierra Guiza, Alejandro (Alex) wrote:
>
> On 6/21/2022 7:25 AM, David Hildenbrand wrote:
>> On 21.06.22 13:55, Alistair Popple wrote:
>>> David Hildenbrand writes:
>>>
>>>> On 21.06.22 13:25, Felix Kuehling wrote:
>>>>>
On 23.06.22 01:16, Sierra Guiza, Alejandro (Alex) wrote:
>
> On 6/21/2022 11:16 AM, David Hildenbrand wrote:
>> On 21.06.22 18:08, Sierra Guiza, Alejandro (Alex) wrote:
>>> On 6/21/2022 7:25 AM, David Hildenbrand wrote:
>>>> On 21.06.22 13:55, Alistair Popp
On 12.07.23 16:38, Kefeng Wang wrote:
Introduce the two helpers for general use.
Signed-off-by: Kefeng Wang
---
include/linux/mm.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 1462cf15badf..0bbeb31ac750 100644
--- a/include/l
On 12.07.23 16:38, Kefeng Wang wrote:
Use the helpers to simplify code.
Signed-off-by: Kefeng Wang
---
fs/proc/task_mmu.c | 24
fs/proc/task_nommu.c | 15 +--
2 files changed, 5 insertions(+), 34 deletions(-)
Please squash patch #1 and this patch an
e = "[stack]";
- goto cpy_name;
- }
-
- name = "//anon";
- goto cpy_name;
If you're removing that goto, maybe also worth removing the goto at the
end of the previous if branch.
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
d long)ALIGN_DOWN(addr, 2UL << 8));
Certainly a valid refactoring, although questionable if such code should
care about that.
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
On 19.07.23 09:51, Kefeng Wang wrote:
Factor out VMA stack and heap checks and name them
vma_is_initial_stack() and vma_is_initial_heap() for
general use.
Cc: Christian Göttsche
Cc: David Hildenbrand
Signed-off-by: Kefeng Wang
---
[...]
diff --git a/include/linux/mm.h b/include/linux
vma->vm_end >= vma->vm_mm->start_stack) ||
+ } else if (!vma->vm_file && (vma_is_initial_stack(vma) ||
vma_is_stack_for_current(vma))) {
rc = avc_has_perm(sid, sid, SECCLASS_PROCESS,
PROCESS__EXECSTACK, NULL);
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
69 matches
Mail list logo
