Re: [PATCH v5 01/13] mm: add zone device coherent type memory support
On Fri, Jun 17, 2022 at 8:20 PM 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 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 memory so that it can always be
> >> evicted.
> >>
> >> Signed-off-by: Alex Sierra
> >> Acked-by: Felix Kuehling
> >> Reviewed-by: Alistair Popple
> >> [hch: rebased ontop of the refcount changes,
> >>removed is_dev_private_or_coherent_page]
> >> Signed-off-by: Christoph Hellwig
> >> ---
> >> include/linux/memremap.h | 19 +++
> >> mm/memcontrol.c | 7 ---
> >> mm/memory-failure.c | 8 ++--
> >> mm/memremap.c| 10 ++
> >> mm/migrate_device.c | 16 +++-
> >> mm/rmap.c| 5 +++--
> >> 6 files changed, 49 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> >> index 8af304f6b504..9f752ebed613 100644
> >> --- a/include/linux/memremap.h
> >> +++ b/include/linux/memremap.h
> >> @@ -41,6 +41,13 @@ struct vmem_altmap {
> >>* A more complete discussion of unaddressable memory may be found in
> >>* include/linux/hmm.h and Documentation/vm/hmm.rst.
> >>*
> >> + * MEMORY_DEVICE_COHERENT:
> >> + * 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). A
> >> + * driver can hotplug the device memory using ZONE_DEVICE and with that
> >> memory
> >> + * type. Any page of a process can be migrated to such memory. However no
> >> one
> > Any page might not be right, I'm pretty sure. ... just thinking about
> > special pages
> > like vdso, shared zeropage, ... pinned pages ...
>
> Hi David,
>
> Yes, I think you're right. This type does not cover all special pages.
> I need to correct that on the cover letter.
> Pinned pages are allowed as long as they're not long term pinned.
>
> Regards,
> Alex Sierra
What if I want to hotplug this device's coherent memory, but I do
*not* want the OS
to migrate any page to it ?
I want to fully-control what resides on this memory, as I can consider
this memory
"expensive". i.e. I don't have a lot of it, I want to use it for
specific purposes and
I don't want the OS to start using it when there is some memory pressure in
the system.
Oded
>
> >
> >> + * should be allowed to pin such memory so that it can always be evicted.
> >> + *
> >>* MEMORY_DEVICE_FS_DAX:
> >>* Host memory that has similar access semantics as System RAM i.e. DMA
> >>* coherent and supports page pinning. In support of coordinating page
> >> @@ -61,6 +68,7 @@ struct vmem_altmap {
> >> enum memory_type {
> >> /* 0 is reserved to catch uninitialized type fields */
> >> MEMORY_DEVICE_PRIVATE = 1,
> >> +MEMORY_DEVICE_COHERENT,
> >> MEMORY_DEVICE_FS_DAX,
> >> MEMORY_DEVICE_GENERIC,
> >> MEMORY_DEVICE_PCI_P2PDMA,
> >> @@ -143,6 +151,17 @@ static inline bool folio_is_device_private(const
> >> struct folio *folio)
> > In general, this LGTM, and it should be correct with PageAnonExclusive I
> > think.
> >
> >
> > However, where exactly is pinning forbidden?
>
> Long-term pinning is forbidden since it would interfere with the device
> memory manager owning the
> device-coherent pages (e.g. evictions in TTM). However, normal pinning
> is allowed on this device type.
>
> Regards,
> Alex Sierra
>
> >
Re: [PATCH v5 00/13] Add MEMORY_DEVICE_COHERENT for coherent device memory mapping
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 told not to do so! > I want to double-check some things regarding PageAnonExclusive interaction. I'm busy, but I'll try prioritizing it. -- Thanks, David / dhildenb
Re: [PATCH v5 02/13] mm: handling Non-LRU pages returned by vm_normal_pages
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 or THP.
>
> We also introduced a FOLL_LRU flag that adds the same behaviour to
> follow_page and related APIs, to allow callers to specify that they
> expect to put pages on an LRU list.
>
> Signed-off-by: Alex Sierra
> Acked-by: Felix Kuehling
> ---
> fs/proc/task_mmu.c | 2 +-
> include/linux/mm.h | 3 ++-
> mm/gup.c | 6 +-
> mm/huge_memory.c | 2 +-
> mm/khugepaged.c| 9 ++---
> mm/ksm.c | 6 +++---
> mm/madvise.c | 4 ++--
> mm/memory.c| 9 -
> mm/mempolicy.c | 2 +-
> mm/migrate.c | 4 ++--
> mm/mlock.c | 2 +-
> mm/mprotect.c | 2 +-
> 12 files changed, 33 insertions(+), 18 deletions(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 2d04e3470d4c..2dd8c8a66924 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1792,7 +1792,7 @@ static struct page *can_gather_numa_stats(pte_t pte,
> struct vm_area_struct *vma,
> return NULL;
>
> page = vm_normal_page(vma, addr, pte);
> - if (!page)
> + if (!page || is_zone_device_page(page))
> return NULL;
>
> if (PageReserved(page))
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index bc8f326be0ce..d3f43908ff8d 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -601,7 +601,7 @@ struct vm_operations_struct {
> #endif
> /*
>* Called by vm_normal_page() for special PTEs to find the
> - * page for @addr. This is useful if the default behavior
> + * page for @addr. This is useful if the default behavior
>* (using pte_page()) would not find the correct page.
>*/
> struct page *(*find_special_page)(struct vm_area_struct *vma,
> @@ -2934,6 +2934,7 @@ struct page *follow_page(struct vm_area_struct *vma,
> unsigned long address,
> #define FOLL_NUMA0x200 /* force NUMA hinting page fault */
> #define FOLL_MIGRATION 0x400 /* wait for page to replace migration
> entry */
> #define FOLL_TRIED 0x800 /* a retry, previous pass started an IO */
> +#define FOLL_LRU0x1000 /* return only LRU (anon or page cache) */
Does that statement hold for special pages like the shared zeropage?
Also, this flag is only valid for in-kernel follow_page() but not for
the ordinary GUP interfaces. What are the semantics there? Is it fenced?
I really wonder if you should simply similarly teach the handful of
users of follow_page() to just special case these pages ... sounds
cleaner to me then adding flags with unclear semantics. Alternatively,
properly document what that flag is actually doing and where it applies.
I know, there was discussion on ... sorry for jumping in now, but this
doesn't look clean to me yet.
--
Thanks,
David / dhildenb
Re: [PATCH v5 01/13] mm: add zone device coherent type memory support
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 memory so that it can always be
> evicted.
>
> Signed-off-by: Alex Sierra
> Acked-by: Felix Kuehling
> Reviewed-by: Alistair Popple
> [hch: rebased ontop of the refcount changes,
> removed is_dev_private_or_coherent_page]
> Signed-off-by: Christoph Hellwig
> ---
> include/linux/memremap.h | 19 +++
> mm/memcontrol.c | 7 ---
> mm/memory-failure.c | 8 ++--
> mm/memremap.c| 10 ++
> mm/migrate_device.c | 16 +++-
> mm/rmap.c| 5 +++--
> 6 files changed, 49 insertions(+), 16 deletions(-)
>
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index 8af304f6b504..9f752ebed613 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -41,6 +41,13 @@ struct vmem_altmap {
> * A more complete discussion of unaddressable memory may be found in
> * include/linux/hmm.h and Documentation/vm/hmm.rst.
> *
> + * MEMORY_DEVICE_COHERENT:
> + * 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).
> A
> + * driver can hotplug the device memory using ZONE_DEVICE and with that
> memory
> + * type. Any page of a process can be migrated to such memory. However no one
Any page might not be right, I'm pretty sure. ... just thinking about special
pages
like vdso, shared zeropage, ... pinned pages ...
> + * should be allowed to pin such memory so that it can always be evicted.
> + *
> * MEMORY_DEVICE_FS_DAX:
> * Host memory that has similar access semantics as System RAM i.e. DMA
> * coherent and supports page pinning. In support of coordinating page
> @@ -61,6 +68,7 @@ struct vmem_altmap {
> enum memory_type {
> /* 0 is reserved to catch uninitialized type fields */
> MEMORY_DEVICE_PRIVATE = 1,
> + MEMORY_DEVICE_COHERENT,
> MEMORY_DEVICE_FS_DAX,
> MEMORY_DEVICE_GENERIC,
> MEMORY_DEVICE_PCI_P2PDMA,
> @@ -143,6 +151,17 @@ static inline bool folio_is_device_private(const struct
> folio *folio)
In general, this LGTM, and it should be correct with PageAnonExclusive I think.
However, where exactly is pinning forbidden?
--
Thanks,
David / dhildenb
Re: [PATCH v5 01/13] mm: add zone device coherent type memory support
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 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 memory so that it can always be
>>> evicted.
>>>
>>> Signed-off-by: Alex Sierra
>>> Acked-by: Felix Kuehling
>>> Reviewed-by: Alistair Popple
>>> [hch: rebased ontop of the refcount changes,
>>>removed is_dev_private_or_coherent_page]
>>> Signed-off-by: Christoph Hellwig
>>> ---
>>> include/linux/memremap.h | 19 +++
>>> mm/memcontrol.c | 7 ---
>>> mm/memory-failure.c | 8 ++--
>>> mm/memremap.c| 10 ++
>>> mm/migrate_device.c | 16 +++-
>>> mm/rmap.c| 5 +++--
>>> 6 files changed, 49 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
>>> index 8af304f6b504..9f752ebed613 100644
>>> --- a/include/linux/memremap.h
>>> +++ b/include/linux/memremap.h
>>> @@ -41,6 +41,13 @@ struct vmem_altmap {
>>>* A more complete discussion of unaddressable memory may be found in
>>>* include/linux/hmm.h and Documentation/vm/hmm.rst.
>>>*
>>> + * MEMORY_DEVICE_COHERENT:
>>> + * 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). A
>>> + * driver can hotplug the device memory using ZONE_DEVICE and with that
>>> memory
>>> + * type. Any page of a process can be migrated to such memory. However no
>>> one
>> Any page might not be right, I'm pretty sure. ... just thinking about
>> special pages
>> like vdso, shared zeropage, ... pinned pages ...
>
Well, you cannot migrate long term pages, that's what I meant :)
>>
>>> + * should be allowed to pin such memory so that it can always be evicted.
>>> + *
>>>* MEMORY_DEVICE_FS_DAX:
>>>* Host memory that has similar access semantics as System RAM i.e. DMA
>>>* coherent and supports page pinning. In support of coordinating page
>>> @@ -61,6 +68,7 @@ struct vmem_altmap {
>>> enum memory_type {
>>> /* 0 is reserved to catch uninitialized type fields */
>>> MEMORY_DEVICE_PRIVATE = 1,
>>> + MEMORY_DEVICE_COHERENT,
>>> MEMORY_DEVICE_FS_DAX,
>>> MEMORY_DEVICE_GENERIC,
>>> MEMORY_DEVICE_PCI_P2PDMA,
>>> @@ -143,6 +151,17 @@ static inline bool folio_is_device_private(const
>>> struct folio *folio)
>> In general, this LGTM, and it should be correct with PageAnonExclusive I
>> think.
>>
>>
>> However, where exactly is pinning forbidden?
>
> Long-term pinning is forbidden since it would interfere with the device
> memory manager owning the
> device-coherent pages (e.g. evictions in TTM). However, normal pinning
> is allowed on this device type.
I don't see updates to folio_is_pinnable() in this patch.
So wouldn't try_grab_folio() simply pin these pages? What am I missing?
--
Thanks,
David / dhildenb
Re: [PATCH v5 00/13] Add MEMORY_DEVICE_COHERENT for coherent device memory mapping
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 told not to do so!
[PATCH] drm/amd/display: Remove unused variable 'abo'
From: "Souptick Joarder (HPE)" Kernel test robot throws below warning -> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9143:27: warning: variable 'abo' set but not used [-Wunused-but-set-variable] Remove the unused variable. Reported-by: Kernel test robot Signed-off-by: Souptick Joarder (HPE) --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index c9004f7e700d..0103b34aabdd 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -9136,7 +9136,6 @@ static void amdgpu_dm_commit_planes(struct drm_atomic_state *state, to_dm_crtc_state(drm_atomic_get_old_crtc_state(state, pcrtc)); int planes_count = 0, vpos, hpos; unsigned long flags; - struct amdgpu_bo *abo; uint32_t target_vblank, last_flip_vblank; bool vrr_active = amdgpu_dm_vrr_active(acrtc_state); bool pflip_present = false; @@ -9208,7 +9207,6 @@ static void amdgpu_dm_commit_planes(struct drm_atomic_state *state, continue; } - abo = gem_to_amdgpu_bo(fb->obj[0]); fill_dc_plane_info_and_addr( dm->adev, new_plane_state, afb->tiling_flags, -- 2.25.1
Re: [PATCH 2/3] Documentation/gpu: Add an explanation about the DCN pipeline
On Thu, 16 Jun 2022 17:59:21 -0400 Rodrigo Siqueira Jordao wrote: > On 2022-06-15 07:12, Pekka Paalanen wrote: > > On Mon, 13 Jun 2022 16:01:11 -0400 > > Rodrigo Siqueira wrote: > > > >> In the DCN code, we constantly talk about hardware pipeline, pipeline, > >> or even just pipes, which is a concept that is not obvious to everyone. > >> For this reason, this commit expands the DCN overview explanation by > >> adding a new section that describes what a pipeline is from the DCN > >> perspective. > >> > >> Cc: Harry Wentland > >> Cc: Nicholas Kazlauskas > >> Cc: Bhawanpreet Lakha > >> Cc: Hersen Wu > >> Cc: Alex Hung > >> Cc: Pierre-Eric Pelloux-Prayer > >> Cc: Leo Li > >> Cc: Simon Ser > >> Cc: Pekka Paalanen > >> Cc: Sean Paul > >> Cc: Mark Yacoub > >> Cc: Pierre-Loup > >> Cc: Michel Dänzer > >> Signed-off-by: Rodrigo Siqueira > >> --- > >> .../gpu/amdgpu/display/dcn-overview.rst | 58 + > >> .../amdgpu/display/pipeline_4k_no_split.svg | 958 +++ > >> .../gpu/amdgpu/display/pipeline_4k_split.svg | 1062 + > >> 3 files changed, 2078 insertions(+) > >> create mode 100644 > >> Documentation/gpu/amdgpu/display/pipeline_4k_no_split.svg > >> create mode 100644 Documentation/gpu/amdgpu/display/pipeline_4k_split.svg > >> > >> diff --git a/Documentation/gpu/amdgpu/display/dcn-overview.rst > >> b/Documentation/gpu/amdgpu/display/dcn-overview.rst > >> index f98624d7828e..430e363fccae 100644 > >> --- a/Documentation/gpu/amdgpu/display/dcn-overview.rst > >> +++ b/Documentation/gpu/amdgpu/display/dcn-overview.rst > >> @@ -124,6 +124,64 @@ depth format), bit-depth reduction/dithering would > >> kick in. In OPP, we would > >> also apply a regamma function to introduce the gamma removed earlier > >> back. > >> Eventually, we output data in integer format at DIO. > >> > > > > Hi, > > > > always nice to see more docs! > > Hi Pekka, > > First of all, thanks for your review. > > > > >> +AMD Hardware Pipeline > >> +- > >> + > >> +When discussing graphics on Linux, the **pipeline** term is often > >> overloaded > >> +with multiple meanings, and DCN adds another context to this word. In the > >> DCN > >> +driver, we use the term **hardware pipeline** or **pipeline** or just > >> **pipe** > >> +to indicate how many DCN blocks we are instantiating to address some > >> specific > > > > This seems to say that a "pipeline" is a number, a count (how many). > > > >> +configuration. DCN composes those pipelines together when the data reach > >> the > > > > This seems to imply that each "DCN block" is "a pipeline". > > > > Is either true? Is a pipeline not a sequence of selected DCN blocks > > instead? > > In the DCN we can have different pipeline configurations. For example, > see the below picture: > > > https://www.kernel.org/doc/html/latest/gpu/amdgpu/display/dcn-overview.html > > Let's say that our pipeline policy does not allow pipe split, in that > case we will have just one instance of each component. However, if we > decided to split our pipe, we will have more instance of the other > components (e.g., 2 DPP). I added some examples about it a little bit > below in this patch. > > Try to apply my series in your local kernel [1]. That way you will be > able to open the svg files at Documentation/gpu/amdgpu/display/. Sorry, that's too much to ask for patch review on a project I don't work on. > Maybe I can rephrase it, do you have some suggestions? I'm not sure what your definition of a pipeline is. If you have split blocks, does that mean you have one pipeline or multiple pipelines? Does block splitting allow to create multiple pipelines in the sense that they do not all contain the exact same blocks? The only thing I could suggest is to not say that a pipeline is a count. That would be done by replacing "to indicate how many DCN blocks" by "to indicate which DCN blocks". Thanks, pq > 1. https://patchwork.freedesktop.org/series/105071/ > > Thanks > Siqueira > > >> +end of the OPTC block before sending it to the display. We have this > >> pipeline > >> +concept for trying to save energy and optimize bandwidth utilization while > >> +providing the maximum performance per watt. It is easier to discuss it if > >> we > >> +dive into this topic by taking the example of a 4k display in the below > >> +example: > >> + > >> +.. kernel-figure:: pipeline_4k_no_split.svg > > > > A bit too hard for me to look at SVGs from email patches, sorry. > > > > You wouldn't happen to have a git branch available in Gitlab or Github > > or even cgit somewhere I could visit with my browser? > > > > > > Thanks, > > pq
Re: [PATCH v5 01/13] mm: add zone device coherent type memory support
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:
> 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 memory so that it can always be
> evicted.
>
> Signed-off-by: Alex Sierra
> Acked-by: Felix Kuehling
> Reviewed-by: Alistair Popple
> [hch: rebased ontop of the refcount changes,
> removed is_dev_private_or_coherent_page]
> Signed-off-by: Christoph Hellwig
> ---
>include/linux/memremap.h | 19 +++
>mm/memcontrol.c | 7 ---
>mm/memory-failure.c | 8 ++--
>mm/memremap.c| 10 ++
>mm/migrate_device.c | 16 +++-
>mm/rmap.c| 5 +++--
>6 files changed, 49 insertions(+), 16 deletions(-)
>
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index 8af304f6b504..9f752ebed613 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -41,6 +41,13 @@ struct vmem_altmap {
> * A more complete discussion of unaddressable memory may be found in
> * include/linux/hmm.h and Documentation/vm/hmm.rst.
> *
> + * MEMORY_DEVICE_COHERENT:
> + * 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). A
> + * driver can hotplug the device memory using ZONE_DEVICE and with that
> memory
> + * type. Any page of a process can be migrated to such memory. However
> no one
Any page might not be right, I'm pretty sure. ... just thinking about
special pages
like vdso, shared zeropage, ... pinned pages ...
>> Well, you cannot migrate long term pages, that's what I meant :)
>>
> + * should be allowed to pin such memory so that it can always be evicted.
> + *
> * MEMORY_DEVICE_FS_DAX:
> * Host memory that has similar access semantics as System RAM i.e. DMA
> * coherent and supports page pinning. In support of coordinating page
> @@ -61,6 +68,7 @@ struct vmem_altmap {
>enum memory_type {
> /* 0 is reserved to catch uninitialized type fields */
> MEMORY_DEVICE_PRIVATE = 1,
> + MEMORY_DEVICE_COHERENT,
> MEMORY_DEVICE_FS_DAX,
> MEMORY_DEVICE_GENERIC,
> MEMORY_DEVICE_PCI_P2PDMA,
> @@ -143,6 +151,17 @@ static inline bool folio_is_device_private(const
> struct folio *folio)
In general, this LGTM, and it should be correct with PageAnonExclusive I
think.
However, where exactly is pinning forbidden?
>>> Long-term pinning is forbidden since it would interfere with the device
>>> memory manager owning the
>>> device-coherent pages (e.g. evictions in TTM). However, normal pinning
>>> is allowed on this device type.
>> I don't see updates to folio_is_pinnable() in this patch.
> Device coherent type pages should return true here, as they are pinnable
> pages.
That function is only called for long-term pinnings in try_grab_folio().
>>
>> So wouldn't try_grab_folio() simply pin these pages? What am I missing?
>
> As far as I understand this return NULL for long term pin pages.
> Otherwise they get refcount incremented.
I don't follow.
You're saying
a) folio_is_pinnable() returns true for device coherent pages
and that
b) device coherent pages don't get long-term pinned
Yet, the code says
struct folio *try_grab_folio(struct page *page, int refs, unsigned int flags)
{
if (flags & FOLL_GET)
return try_get_folio(page, refs);
else if (flags & FOLL_PIN) {
struct folio *folio;
/*
* Can't do FOLL_LONGTERM + FOLL_PIN gup fast path if not in a
* right zone, so fail and let the caller fall back to the slow
* path.
*/
if (unlikely((flags & FOLL_LONGTERM) &&
!is_pinnable_page(page)))
return NULL;
...
return folio;
}
}
What prevents these pages from getting long-term pinned as stated in this patch?
I am probably missing something important.
--
Thanks,
David / dhildenb
Re: [PATCH] drm/radeon: Add build directory to include path
On Wed, Jun 15, 2022 at 5:35 PM Michel Dänzer wrote: > > On 2022-04-14 18:57, Michel Dänzer wrote: > > On 2022-04-14 17:04, Masahiro Yamada wrote: > >> On Thu, Apr 14, 2022 at 10:50 PM Michel Dänzer > >> wrote: > >>> On 2022-04-14 15:34, Alex Deucher wrote: > On Thu, Apr 14, 2022 at 4:44 AM Christian König > wrote: > > Am 14.04.22 um 09:37 schrieb Michel Dänzer: > >> > >> make -C build-amd64 M=drivers/gpu/drm > >> > >> > >> Maybe > >> > >> make O=build-arm64 drivers/gpu/drm/ > >> > >> is the way you were searching for. > >> > >> It builds only drivers/gpu/drm/ > >> in the separate directory. > > > > Indeed, that works. > > I've come to realize that this doesn't produce the actual *.ko modules > though. Is there a trick for building the modules, but only under > drivers/gpu/drm/ ? > > > -- > Earthling Michel Dänzer| https://redhat.com > Libre software enthusiast | Mesa and Xwayland developer No. There is no way to build *.ko only under a specific directory. -- Best Regards Masahiro Yamada
