Am 04.12.20 um 09:32 schrieb Thomas Zimmermann:
> Hi
>
> Am 03.12.20 um 21:41 schrieb Daniel Vetter:
>> On Thu, Dec 03, 2020 at 07:59:04PM +0100, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 03.12.20 um 16:26 schrieb Daniel Vetter:
>>>> On Thu, Dec 03, 2020 at 03:02:59PM +0100, Thomas Zimmermann wrote:
>>>>> Dma-buf's vmap and vunmap callbacks are undocumented and various
>>>>> exporters currently have slightly different semantics for them. Add
>>>>> documentation on how to implement and use these interfaces correctly.
>>>>>
>>>>> v2:
>>>>> * document vmap semantics in struct dma_buf_ops
>>>>> * add TODO item for reviewing and maybe fixing dma-buf exporters
>>>>>
>>>>> Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de>
>>>>
>>>> I still don't think this works, we're breaking dma_buf_vmap for
>>>> everyone
>>>> else here.
>>>
>>> I removed the text on the importer. These notes for callers in the
>>> docs are
>>> more or less a consequence of the exporter semantics.
>>
>> Callers are importers, so I'm not seeing how that fixes anything.
>>
>>> I thought we at least agreed on the exporter semantics in the other
>>> thread,
>>> didn't we?
>>>
>>> What I'm trying to do is to write dome some rules for exporters,
>>> even if not
>>> all exporters follow them.
>>
>> This is a standard interface, everyone needs to follow the same
>> rules. And
>> if they change, we need to make sure nothing breaks and we're not
>> creating
>> issues.
>>
>> In the past the rule was the dma_buf_vmap was allowed to take the
>> dma_resv_lock, and that the buffer should be pinned. Now some ttm
>> drivers
>> didn't ever bother with the pinning, and mostly got away with that
>> because
>> drm_prime helpers do the pinning by default at attach time, and most
>> users
>> do call dma_buf_attach.
>>
>> But if you look through dma-buf docs nothing ever said you have to do a
>> dummy attachment before you call dma_buf_vmap, that's just slightly
>> crappy
>> implementations that didn't blow up yet.
>
> I had a patch for adding pin to radeon's implementation of vmap. [1]
> Christian told me to not do this; instead just get the lock in the
> fbdev code. His advise almost seems the opposite of what you're
> telling me here.
I think what Daniel suggests here is that we need to smoothly transition
the code from making assumptions to having a straight interface where
importers explicitly say when stuff is locked and when stuff is pinned.
I've started this with the attach interface by adding a new dynamic
approach to that, but you probably need to carry on here with that for
vmap as well.
When that is done we can migrate every exporter over to the new dynamic
approach.
>
> For the GEM VRAM helpers, that implicit pin in vmap gave me headaches.
> Because scanouts can only be done from VRAM, which is badly suited for
> exporting. So I ended up with an implicit pin that pins the buffer to
> whatever domain it currently is. I got away with it because GEM VRAM
> BOs are not sharable among devices; fbdev is the only user of that
> functionality and only pins for short periods of time.
>
> I suspect that fixing TTM-based drivers by adding an implicit pin
> would result in a similar situation. Whatever domain it ends up
> pinning, some functionality might not be compatible with that.
Correct, exactly that's the problem.
>
>>
>>> Given the circumstances, we should leave out this patch from the
>>> patchset.
>>
>> So the defacto rules are already a big mess, but that's not a good
>> excuse
>> to make it worse.
>>
>> What I had in mind is that we split dma_buf_vmap up into two variants:
>>
>> - The current one, which should guarantee that the buffer is pinned.
>> Because that's what all current callers wanted, before the fbdev code
>> started allowing non-pinned buffers.
>
> Can we add an explicit pin operation to dma_buf_vmap() to enforce the
> semantics?
At least I would be fine with that. For now amdgpu is the only exporter
who implements the explicit pin/unpin semantics anyway.
Regards,
Christian.
>
> Best regards
> Thomas
>
> [1] https://patchwork.freedesktop.org/patch/400054/?series=83765&rev=1
>
>>
>> - The new one, which allows vmapping with just dma_resv locked, and
>> should
>> have some caching in exporters.
>>
>> Breaking code and then adding todos about that is kinda not so cool
>> approach here imo.
>>
>> Also I guess ttm_bo_vmap should have a check that either the buffer is
>> pinned, or dma_resv_lock is held.
>>
>> Cheers, Daniel
>>
>>
>>
>>>
>>> Best regards
>>> Thomas
>>>
>>>>
>>>>> ---
>>>>> Documentation/gpu/todo.rst | 15 +++++++++++++
>>>>> include/drm/drm_gem.h | 4 ++++
>>>>> include/linux/dma-buf.h | 45
>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>> 3 files changed, 64 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
>>>>> index 009d8e6c7e3c..32bb797a84fc 100644
>>>>> --- a/Documentation/gpu/todo.rst
>>>>> +++ b/Documentation/gpu/todo.rst
>>>>> @@ -505,6 +505,21 @@ Contact: Thomas Zimmermann
>>>>> <tzimmermann(a)suse.de>, Christian König, Daniel Vette
>>>>> Level: Intermediate
>>>>> +Enforce rules for dma-buf vmap and pin ops
>>>>> +------------------------------------------
>>>>> +
>>>>> +Exporter implementations of vmap and pin in struct dma_buf_ops
>>>>> (and consequently
>>>>> +struct drm_gem_object_funcs) use a variety of locking semantics.
>>>>> Some rely on
>>>>> +the caller holding the dma-buf's reservation lock, some do their
>>>>> own locking,
>>>>> +some don't require any locking. VRAM helpers even used to pin as
>>>>> part of vmap.
>>>>> +
>>>>> +We need to review each exporter and enforce the documented rules.
>>>>> +
>>>>> +Contact: Christian König, Daniel Vetter, Thomas Zimmermann
>>>>> <tzimmermann(a)suse.de>
>>>>> +
>>>>> +Level: Advanced
>>>>> +
>>>>> +
>>>>> Core refactorings
>>>>> =================
>>>>> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
>>>>> index 5e6daa1c982f..1864c6a721b1 100644
>>>>> --- a/include/drm/drm_gem.h
>>>>> +++ b/include/drm/drm_gem.h
>>>>> @@ -138,6 +138,8 @@ struct drm_gem_object_funcs {
>>>>> * drm_gem_dmabuf_vmap() helper.
>>>>> *
>>>>> * This callback is optional.
>>>>> + *
>>>>> + * See also struct dma_buf_ops.vmap
>>>>> */
>>>>> int (*vmap)(struct drm_gem_object *obj, struct dma_buf_map
>>>>> *map);
>>>>> @@ -148,6 +150,8 @@ struct drm_gem_object_funcs {
>>>>> * drm_gem_dmabuf_vunmap() helper.
>>>>> *
>>>>> * This callback is optional.
>>>>> + *
>>>>> + * See also struct dma_buf_ops.vunmap
>>>>> */
>>>>> void (*vunmap)(struct drm_gem_object *obj, struct
>>>>> dma_buf_map *map);
>>>>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>>>>> index cf72699cb2bc..dc81fdc01dda 100644
>>>>> --- a/include/linux/dma-buf.h
>>>>> +++ b/include/linux/dma-buf.h
>>>>> @@ -267,7 +267,52 @@ struct dma_buf_ops {
>>>>> */
>>>>> int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
>>>>> + /**
>>>>> + * @vmap:
>>>>
>>>> There's already a @vmap and @vunamp kerneldoc at the top comment, that
>>>> needs to be removed.
>>>> -Daniel
>>>>
>>>>> + *
>>>>> + * Returns a virtual address for the buffer.
>>>>> + *
>>>>> + * Notes to callers:
>>>>> + *
>>>>> + * - Callers must hold the struct dma_buf.resv lock before
>>>>> calling
>>>>> + * this interface.
>>>>> + *
>>>>> + * - Callers must provide means to prevent the mappings from
>>>>> going
>>>>> + * stale, such as holding the reservation lock or providing a
>>>>> + * move-notify callback to the exporter.
>>>>> + *
>>>>> + * Notes to implementors:
>>>>> + *
>>>>> + * - Implementations must expect pairs of @vmap and @vunmap
>>>>> to be
>>>>> + * called frequently and should optimize for this case.
>>>>> + *
>>>>> + * - Implementations should avoid additional operations, such as
>>>>> + * pinning.
>>>>> + *
>>>>> + * - Implementations may expect the caller to hold the dma-buf's
>>>>> + * reservation lock to protect against concurrent calls and
>>>>> + * relocation.
>>>>> + *
>>>>> + * - Implementations may provide additional guarantees, such
>>>>> as working
>>>>> + * without holding the reservation lock.
>>>>> + *
>>>>> + * This callback is optional.
>>>>> + *
>>>>> + * Returns:
>>>>> + *
>>>>> + * 0 on success or a negative error code on failure.
>>>>> + */
>>>>> int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
>>>>> +
>>>>> + /**
>>>>> + * @vunmap:
>>>>> + *
>>>>> + * Releases the address previously returned by @vmap.
>>>>> + *
>>>>> + * This callback is optional.
>>>>> + *
>>>>> + * See also @vmap()
>>>>> + */
>>>>> void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map
>>>>> *map);
>>>>> };
>>>>> --
>>>>> 2.29.2
>>>>>
>>>>
>>>
>>> --
>>> Thomas Zimmermann
>>> Graphics Driver Developer
>>> SUSE Software Solutions Germany GmbH
>>> Maxfeldstr. 5, 90409 Nürnberg, Germany
>>> (HRB 36809, AG Nürnberg)
>>> Geschäftsführer: Felix Imendörffer
>>>
>>
>>
>>
>>
>
On Thu, Dec 03, 2020 at 07:59:04PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 03.12.20 um 16:26 schrieb Daniel Vetter:
> > On Thu, Dec 03, 2020 at 03:02:59PM +0100, Thomas Zimmermann wrote:
> > > Dma-buf's vmap and vunmap callbacks are undocumented and various
> > > exporters currently have slightly different semantics for them. Add
> > > documentation on how to implement and use these interfaces correctly.
> > >
> > > v2:
> > > * document vmap semantics in struct dma_buf_ops
> > > * add TODO item for reviewing and maybe fixing dma-buf exporters
> > >
> > > Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de>
> >
> > I still don't think this works, we're breaking dma_buf_vmap for everyone
> > else here.
>
> I removed the text on the importer. These notes for callers in the docs are
> more or less a consequence of the exporter semantics.
Callers are importers, so I'm not seeing how that fixes anything.
> I thought we at least agreed on the exporter semantics in the other thread,
> didn't we?
>
> What I'm trying to do is to write dome some rules for exporters, even if not
> all exporters follow them.
This is a standard interface, everyone needs to follow the same rules. And
if they change, we need to make sure nothing breaks and we're not creating
issues.
In the past the rule was the dma_buf_vmap was allowed to take the
dma_resv_lock, and that the buffer should be pinned. Now some ttm drivers
didn't ever bother with the pinning, and mostly got away with that because
drm_prime helpers do the pinning by default at attach time, and most users
do call dma_buf_attach.
But if you look through dma-buf docs nothing ever said you have to do a
dummy attachment before you call dma_buf_vmap, that's just slightly crappy
implementations that didn't blow up yet.
> Given the circumstances, we should leave out this patch from the patchset.
So the defacto rules are already a big mess, but that's not a good excuse
to make it worse.
What I had in mind is that we split dma_buf_vmap up into two variants:
- The current one, which should guarantee that the buffer is pinned.
Because that's what all current callers wanted, before the fbdev code
started allowing non-pinned buffers.
- The new one, which allows vmapping with just dma_resv locked, and should
have some caching in exporters.
Breaking code and then adding todos about that is kinda not so cool
approach here imo.
Also I guess ttm_bo_vmap should have a check that either the buffer is
pinned, or dma_resv_lock is held.
Cheers, Daniel
>
> Best regards
> Thomas
>
> >
> > > ---
> > > Documentation/gpu/todo.rst | 15 +++++++++++++
> > > include/drm/drm_gem.h | 4 ++++
> > > include/linux/dma-buf.h | 45 ++++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 64 insertions(+)
> > >
> > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > > index 009d8e6c7e3c..32bb797a84fc 100644
> > > --- a/Documentation/gpu/todo.rst
> > > +++ b/Documentation/gpu/todo.rst
> > > @@ -505,6 +505,21 @@ Contact: Thomas Zimmermann <tzimmermann(a)suse.de>, Christian König, Daniel Vette
> > > Level: Intermediate
> > > +Enforce rules for dma-buf vmap and pin ops
> > > +------------------------------------------
> > > +
> > > +Exporter implementations of vmap and pin in struct dma_buf_ops (and consequently
> > > +struct drm_gem_object_funcs) use a variety of locking semantics. Some rely on
> > > +the caller holding the dma-buf's reservation lock, some do their own locking,
> > > +some don't require any locking. VRAM helpers even used to pin as part of vmap.
> > > +
> > > +We need to review each exporter and enforce the documented rules.
> > > +
> > > +Contact: Christian König, Daniel Vetter, Thomas Zimmermann <tzimmermann(a)suse.de>
> > > +
> > > +Level: Advanced
> > > +
> > > +
> > > Core refactorings
> > > =================
> > > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > > index 5e6daa1c982f..1864c6a721b1 100644
> > > --- a/include/drm/drm_gem.h
> > > +++ b/include/drm/drm_gem.h
> > > @@ -138,6 +138,8 @@ struct drm_gem_object_funcs {
> > > * drm_gem_dmabuf_vmap() helper.
> > > *
> > > * This callback is optional.
> > > + *
> > > + * See also struct dma_buf_ops.vmap
> > > */
> > > int (*vmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
> > > @@ -148,6 +150,8 @@ struct drm_gem_object_funcs {
> > > * drm_gem_dmabuf_vunmap() helper.
> > > *
> > > * This callback is optional.
> > > + *
> > > + * See also struct dma_buf_ops.vunmap
> > > */
> > > void (*vunmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
> > > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > > index cf72699cb2bc..dc81fdc01dda 100644
> > > --- a/include/linux/dma-buf.h
> > > +++ b/include/linux/dma-buf.h
> > > @@ -267,7 +267,52 @@ struct dma_buf_ops {
> > > */
> > > int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
> > > + /**
> > > + * @vmap:
> >
> > There's already a @vmap and @vunamp kerneldoc at the top comment, that
> > needs to be removed.
> > -Daniel
> >
> > > + *
> > > + * Returns a virtual address for the buffer.
> > > + *
> > > + * Notes to callers:
> > > + *
> > > + * - Callers must hold the struct dma_buf.resv lock before calling
> > > + * this interface.
> > > + *
> > > + * - Callers must provide means to prevent the mappings from going
> > > + * stale, such as holding the reservation lock or providing a
> > > + * move-notify callback to the exporter.
> > > + *
> > > + * Notes to implementors:
> > > + *
> > > + * - Implementations must expect pairs of @vmap and @vunmap to be
> > > + * called frequently and should optimize for this case.
> > > + *
> > > + * - Implementations should avoid additional operations, such as
> > > + * pinning.
> > > + *
> > > + * - Implementations may expect the caller to hold the dma-buf's
> > > + * reservation lock to protect against concurrent calls and
> > > + * relocation.
> > > + *
> > > + * - Implementations may provide additional guarantees, such as working
> > > + * without holding the reservation lock.
> > > + *
> > > + * This callback is optional.
> > > + *
> > > + * Returns:
> > > + *
> > > + * 0 on success or a negative error code on failure.
> > > + */
> > > int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> > > +
> > > + /**
> > > + * @vunmap:
> > > + *
> > > + * Releases the address previously returned by @vmap.
> > > + *
> > > + * This callback is optional.
> > > + *
> > > + * See also @vmap()
> > > + */
> > > void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> > > };
> > > --
> > > 2.29.2
> > >
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Dec 03, 2020 at 03:02:59PM +0100, Thomas Zimmermann wrote:
> Dma-buf's vmap and vunmap callbacks are undocumented and various
> exporters currently have slightly different semantics for them. Add
> documentation on how to implement and use these interfaces correctly.
>
> v2:
> * document vmap semantics in struct dma_buf_ops
> * add TODO item for reviewing and maybe fixing dma-buf exporters
>
> Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de>
I still don't think this works, we're breaking dma_buf_vmap for everyone
else here.
> ---
> Documentation/gpu/todo.rst | 15 +++++++++++++
> include/drm/drm_gem.h | 4 ++++
> include/linux/dma-buf.h | 45 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 64 insertions(+)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 009d8e6c7e3c..32bb797a84fc 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -505,6 +505,21 @@ Contact: Thomas Zimmermann <tzimmermann(a)suse.de>, Christian König, Daniel Vette
> Level: Intermediate
>
>
> +Enforce rules for dma-buf vmap and pin ops
> +------------------------------------------
> +
> +Exporter implementations of vmap and pin in struct dma_buf_ops (and consequently
> +struct drm_gem_object_funcs) use a variety of locking semantics. Some rely on
> +the caller holding the dma-buf's reservation lock, some do their own locking,
> +some don't require any locking. VRAM helpers even used to pin as part of vmap.
> +
> +We need to review each exporter and enforce the documented rules.
> +
> +Contact: Christian König, Daniel Vetter, Thomas Zimmermann <tzimmermann(a)suse.de>
> +
> +Level: Advanced
> +
> +
> Core refactorings
> =================
>
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 5e6daa1c982f..1864c6a721b1 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -138,6 +138,8 @@ struct drm_gem_object_funcs {
> * drm_gem_dmabuf_vmap() helper.
> *
> * This callback is optional.
> + *
> + * See also struct dma_buf_ops.vmap
> */
> int (*vmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
>
> @@ -148,6 +150,8 @@ struct drm_gem_object_funcs {
> * drm_gem_dmabuf_vunmap() helper.
> *
> * This callback is optional.
> + *
> + * See also struct dma_buf_ops.vunmap
> */
> void (*vunmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
>
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index cf72699cb2bc..dc81fdc01dda 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -267,7 +267,52 @@ struct dma_buf_ops {
> */
> int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
>
> + /**
> + * @vmap:
There's already a @vmap and @vunamp kerneldoc at the top comment, that
needs to be removed.
-Daniel
> + *
> + * Returns a virtual address for the buffer.
> + *
> + * Notes to callers:
> + *
> + * - Callers must hold the struct dma_buf.resv lock before calling
> + * this interface.
> + *
> + * - Callers must provide means to prevent the mappings from going
> + * stale, such as holding the reservation lock or providing a
> + * move-notify callback to the exporter.
> + *
> + * Notes to implementors:
> + *
> + * - Implementations must expect pairs of @vmap and @vunmap to be
> + * called frequently and should optimize for this case.
> + *
> + * - Implementations should avoid additional operations, such as
> + * pinning.
> + *
> + * - Implementations may expect the caller to hold the dma-buf's
> + * reservation lock to protect against concurrent calls and
> + * relocation.
> + *
> + * - Implementations may provide additional guarantees, such as working
> + * without holding the reservation lock.
> + *
> + * This callback is optional.
> + *
> + * Returns:
> + *
> + * 0 on success or a negative error code on failure.
> + */
> int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> +
> + /**
> + * @vunmap:
> + *
> + * Releases the address previously returned by @vmap.
> + *
> + * This callback is optional.
> + *
> + * See also @vmap()
> + */
> void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> };
>
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On 03.12.20 12:47, Michal Hocko wrote:
> On Thu 03-12-20 10:47:02, David Hildenbrand wrote:
>> On 03.12.20 09:28, Michal Hocko wrote:
> [...]
>>> I think we should aim at easy and very highlevel behavior:
>>> - GFP_NOWAIT - unsupported currently IIRC but something that something
>>> that should be possible to implement. Isolation is non blocking,
>>> migration could be skipped
>>> - GFP_KERNEL - default behavior whatever that means
>>> - GFP_NORETRY - opportunistic allocation as lightweight as we can get.
>>> Failures to be expected also for transient reasons.
>>> - GFP_RETRY_MAYFAIL - try hard but not as hard as to trigger disruption
>>> (e.g. via oom killer).
>>
>> I think we currently see demand for 3 modes for alloc_contig_range()
>>
>> a) normal
>>
>> As is. Try, but don't try too hard. E.g., drain LRU, drain PCP, retry a
>> couple of times. Failures in some cases (short-term pinning, PCP races)
>> are still possible and acceptable.
>>
>> GFP_RETRY_MAYFAIL ?
>
> normal shouldn't really require anybody to think about gfp flags hard.
> That to most people really means GFP_KERNEL.
>
>> E.g., "Allocations with this flag may fail, but only when there is
>> genuinely little unused memory." - current description does not match at
>> all. When allocating ranges things behave completely different.
>>
>>
>> b) fast
>>
>> Try, but fail fast. Leave optimizations that can improve the result to
>> the caller. E.g., don't drain LRU, don't drain PCP, don't retry.
>> Frequent failures are expected and acceptable.
>>
>> __GFP_NORETRY ?
>>
>> E.g., "The VM implementation will try only very lightweight memory
>> direct reclaim to get some memory under memory pressure" - again, I
>> think current description does not really match.
>
> Agreed. As mentioned above this would be an opportunistic allocation
> mode.
>
>
>> c) hard
>>
>> Try hard, E.g., temporarily disabling the PCP. Certainly not
>> __GFP_NOFAIL, that would be highly dangerous. So no flags / GFP_KERNEL?
>
> NOFAIL semantic is out of question. Should we have a mode to try harder
> than the default? I dunno. Do we have users? I think RETRY_MAYFAIL is a
> middle ground between the default and NORETRY which is just too easy to
> fail. This is the case for the allocator as well. And from what I have
> seen people are already using MAYFAIL in order to prevent oom killer so
> this is a generally recognized pattern.
virtio-mem might be one user. It might first try in normal mode to get
as much memory out as possible, but switch to hard mode when it might
make sense.
>
>>> - __GFP_THIS_NODE - stick to a node without fallback
>>> - we can support zone modifiers although there is no existing user.
>>> - __GFP_NOWARN - obvious
>>>
>>> And that is it. Or maybe I am seeing that oversimplified.
>>>
>>
>> Again, I think most flags make sense for the migration target allocation
>> path and mainly deal with OOM situations and reclaim. For the migration
>> path - which is specific to the alloc_contig_range() allocater - they
>> don't really apply and create more confusion than they actually help - IMHO.
>
> Migration is really an implementation detail of this interface. You
> shouldn't be even thinking that there is a migration underneath not even
> mention to actually trying to control it.
CMA? I tend to agree.
alloc_contig_range? I disagree.
--
Thanks,
David / dhildenb
On 03.12.20 09:28, Michal Hocko wrote:
> On Wed 02-12-20 21:22:36, David Hildenbrand wrote:
>> On 02.12.20 20:26, Minchan Kim wrote:
>>> On Wed, Dec 02, 2020 at 07:51:07PM +0100, Michal Hocko wrote:
> [...]
>>>> I am still not sure a specific flag is a good interface. Really can this
>>>> be gfp_mask instead?
>>>
>>> I am not strong(even, I did it with GFP_NORETRY) but David wanted to
>>> have special mode and I agreed when he mentioned ALLOC_CONTIG_HARD as
>>> one of options in future(it would be hard to indicate that mode with
>>> gfp flags).
>>
>> I can't tell regarding the CMA interface, but for the alloc_contig()
>> interface I think modes make sense. Yes, it's different to other
>> allocaters, but the contig range allocater is different already. E.g.,
>> the CMA allocater mostly hides "which exact PFNs you try to allocate".
>
> Yes, alloc_contig_range is a low level API but it already has a gfp_mask
> parameter. Adding yet another allocation mode sounds like API
> convolution to me.
Well, if another parameter is a concern, we can introduce
alloc_contig_range_fast()
instead.
>
>> In the contig range allocater, gfp flags are currently used to express
>> how to allocate pages used as migration targets. I don't think mangling
>> in other gfp flags (or even overloading them) makes things a lot
>> clearer. E.g., GFP_NORETRY: don't retry to allocate migration targets?
>> don't retry to migrate pages? both?
>>
>> As I said, other aspects might be harder to model (e.g., don't drain
>> LRU) and hiding them behind generic gfp flags (e.g., GFP_NORETRY) feels
>> wrong.
>>
>> With the mode, we're expressing details for the necessary page
>> migration. Suggestions on how to model that are welcome.
>
> The question is whether the caller should really have such an intimate
> knowledge and control of the alloc_contig_range implementation. This all
> are implementation details. Should really anybody think about how many
> times migration retries or control LRU draining? Those can change in the
The question is not "how many times", rather "if at all". I can
understand the possible performance improvements by letting the caller
handle things (lru draining, pcp draining) like that when issuing
gazillions of alloc_contig_range() calls.
> future and I do not think we really want to go over all users grown over
> that time and try to deduce what was the intention behind.
That's why I think we need a clear mechanism to express the expected
behavior - something we can properly document and users can actually
understand to optimize for - and we can fix them up when the documented
behavior changes. Mangling this into somewhat-fitting gfp flags makes
the interface harder to use and more error-prone IMHO.
>
> I think we should aim at easy and very highlevel behavior:
> - GFP_NOWAIT - unsupported currently IIRC but something that something
> that should be possible to implement. Isolation is non blocking,
> migration could be skipped
> - GFP_KERNEL - default behavior whatever that means
> - GFP_NORETRY - opportunistic allocation as lightweight as we can get.
> Failures to be expected also for transient reasons.
> - GFP_RETRY_MAYFAIL - try hard but not as hard as to trigger disruption
> (e.g. via oom killer).
I think we currently see demand for 3 modes for alloc_contig_range()
a) normal
As is. Try, but don't try too hard. E.g., drain LRU, drain PCP, retry a
couple of times. Failures in some cases (short-term pinning, PCP races)
are still possible and acceptable.
GFP_RETRY_MAYFAIL ?
E.g., "Allocations with this flag may fail, but only when there is
genuinely little unused memory." - current description does not match at
all. When allocating ranges things behave completely different.
b) fast
Try, but fail fast. Leave optimizations that can improve the result to
the caller. E.g., don't drain LRU, don't drain PCP, don't retry.
Frequent failures are expected and acceptable.
__GFP_NORETRY ?
E.g., "The VM implementation will try only very lightweight memory
direct reclaim to get some memory under memory pressure" - again, I
think current description does not really match.
c) hard
Try hard, E.g., temporarily disabling the PCP. Certainly not
__GFP_NOFAIL, that would be highly dangerous. So no flags / GFP_KERNEL?
>
> - __GFP_THIS_NODE - stick to a node without fallback
> - we can support zone modifiers although there is no existing user.
> - __GFP_NOWARN - obvious
>
> And that is it. Or maybe I am seeing that oversimplified.
>
Again, I think most flags make sense for the migration target allocation
path and mainly deal with OOM situations and reclaim. For the migration
path - which is specific to the alloc_contig_range() allocater - they
don't really apply and create more confusion than they actually help - IMHO.
--
Thanks,
David / dhildenb
On Wed, Dec 02, 2020 at 07:51:07PM +0100, Michal Hocko wrote:
> On Wed 02-12-20 09:54:29, Minchan Kim wrote:
> > On Wed, Dec 02, 2020 at 05:48:34PM +0100, Michal Hocko wrote:
> > > On Wed 02-12-20 08:15:49, Minchan Kim wrote:
> > > > On Wed, Dec 02, 2020 at 04:49:15PM +0100, Michal Hocko wrote:
> > > [...]
> > > > > Well, what I can see is that this new interface is an antipatern to our
> > > > > allocation routines. We tend to control allocations by gfp mask yet you
> > > > > are introducing a bool parameter to make something faster... What that
> > > > > really means is rather arbitrary. Would it make more sense to teach
> > > > > cma_alloc resp. alloc_contig_range to recognize GFP_NOWAIT, GFP_NORETRY resp.
> > > > > GFP_RETRY_MAYFAIL instead?
> > > >
> > > > If we use cma_alloc, that interface requires "allocate one big memory
> > > > chunk". IOW, return value is just struct page and expected that the page
> > > > is a big contiguos memory. That means it couldn't have a hole in the
> > > > range.
> > > > However the idea here, what we asked is much smaller chunk rather
> > > > than a big contiguous memory so we could skip some of pages if they are
> > > > randomly pinned(long-term/short-term whatever) and search other pages
> > > > in the CMA area to avoid long stall. Thus, it couldn't work with exising
> > > > cma_alloc API with simple gfp_mak.
> > >
> > > I really do not see that as something really alient to the cma_alloc
> > > interface. All you should care about, really, is what size of the object
> > > you want and how hard the system should try. If you have a problem with
> > > an internal implementation of CMA and how it chooses a range and deal
> > > with pinned pages then it should be addressed inside the CMA allocator.
> > > I suspect that you are effectivelly trying to workaround those problems
> > > by a side implementation with a slightly different API. Or maybe I still
> > > do not follow the actual problem.
> > >
> > > > > I am not deeply familiar with the cma allocator so sorry for a
> > > > > potentially stupid question. Why does a bulk interface performs better
> > > > > than repeated calls to cma_alloc? Is this because a failure would help
> > > > > to move on to the next pfn range while a repeated call would have to
> > > > > deal with the same range?
> > > >
> > > > Yub, true with other overheads(e.g., migration retrial, waiting writeback
> > > > PCP/LRU draining IPI)
> > >
> > > Why cannot this be implemented in the cma_alloc layer? I mean you can
> > > cache failed cases and optimize the proper pfn range search.
> >
> > So do you suggest this?
> >
> > enum cma_alloc_mode {
> > CMA_ALLOC_NORMAL,
> > CMA_ALLOC_FAIL_FAST,
> > };
> >
> > struct page *cma_alloc(struct cma *cma, size_t count, unsigned int
> > align, enum cma_alloc_mode mode);
> >
> > >From now on, cma_alloc will keep last failed pfn and then start to
> > search from the next pfn for both CMA_ALLOC_NORMAL and
> > CMA_ALLOC_FAIL_FAST if requested size from the cached pfn is okay
> > within CMA area and then wraparound it couldn't find right pages
> > from the cached pfn. Othewise, the cached pfn will reset to the zero
> > so that it starts the search from the 0. I like the idea since it's
> > general improvement, I think.
>
> Yes something like that. There are more options to be clever here - e.g.
> track ranges etc. but I am not sure this is worth the complexity.
Agree. Just last pfn caching would be good enough as simple start.
>
> > Furthemore, With CMA_ALLOC_FAIL_FAST, it could avoid several overheads
> > at the cost of sacrificing allocation success ratio like GFP_NORETRY.
>
> I am still not sure a specific flag is a good interface. Really can this
> be gfp_mask instead?
I am not strong(even, I did it with GFP_NORETRY) but David wanted to
have special mode and I agreed when he mentioned ALLOC_CONTIG_HARD as
one of options in future(it would be hard to indicate that mode with
gfp flags).
>
> > I think that would solve the issue with making the API more flexible.
> > Before diving into it, I'd like to confirm we are on same page.
> > Please correct me if I misunderstood.
>
> I am not sure you are still thinking about a bulk interface.
No I am thinking of just using cma_alloc API with cached pfn
as interal improvement and adding new fast fail mode to the API
so driver could call the API repeatedly until then can get enough
pages.
On Wed, Dec 02, 2020 at 05:48:34PM +0100, Michal Hocko wrote:
> On Wed 02-12-20 08:15:49, Minchan Kim wrote:
> > On Wed, Dec 02, 2020 at 04:49:15PM +0100, Michal Hocko wrote:
> [...]
> > > Well, what I can see is that this new interface is an antipatern to our
> > > allocation routines. We tend to control allocations by gfp mask yet you
> > > are introducing a bool parameter to make something faster... What that
> > > really means is rather arbitrary. Would it make more sense to teach
> > > cma_alloc resp. alloc_contig_range to recognize GFP_NOWAIT, GFP_NORETRY resp.
> > > GFP_RETRY_MAYFAIL instead?
> >
> > If we use cma_alloc, that interface requires "allocate one big memory
> > chunk". IOW, return value is just struct page and expected that the page
> > is a big contiguos memory. That means it couldn't have a hole in the
> > range.
> > However the idea here, what we asked is much smaller chunk rather
> > than a big contiguous memory so we could skip some of pages if they are
> > randomly pinned(long-term/short-term whatever) and search other pages
> > in the CMA area to avoid long stall. Thus, it couldn't work with exising
> > cma_alloc API with simple gfp_mak.
>
> I really do not see that as something really alient to the cma_alloc
> interface. All you should care about, really, is what size of the object
> you want and how hard the system should try. If you have a problem with
> an internal implementation of CMA and how it chooses a range and deal
> with pinned pages then it should be addressed inside the CMA allocator.
> I suspect that you are effectivelly trying to workaround those problems
> by a side implementation with a slightly different API. Or maybe I still
> do not follow the actual problem.
>
> > > I am not deeply familiar with the cma allocator so sorry for a
> > > potentially stupid question. Why does a bulk interface performs better
> > > than repeated calls to cma_alloc? Is this because a failure would help
> > > to move on to the next pfn range while a repeated call would have to
> > > deal with the same range?
> >
> > Yub, true with other overheads(e.g., migration retrial, waiting writeback
> > PCP/LRU draining IPI)
>
> Why cannot this be implemented in the cma_alloc layer? I mean you can
> cache failed cases and optimize the proper pfn range search.
So do you suggest this?
enum cma_alloc_mode {
CMA_ALLOC_NORMAL,
CMA_ALLOC_FAIL_FAST,
};
struct page *cma_alloc(struct cma *cma, size_t count, unsigned int
align, enum cma_alloc_mode mode);
>From now on, cma_alloc will keep last failed pfn and then start to
search from the next pfn for both CMA_ALLOC_NORMAL and
CMA_ALLOC_FAIL_FAST if requested size from the cached pfn is okay
within CMA area and then wraparound it couldn't find right pages
from the cached pfn. Othewise, the cached pfn will reset to the zero
so that it starts the search from the 0. I like the idea since it's
general improvement, I think.
Furthemore, With CMA_ALLOC_FAIL_FAST, it could avoid several overheads
at the cost of sacrificing allocation success ratio like GFP_NORETRY.
I think that would solve the issue with making the API more flexible.
Before diving into it, I'd like to confirm we are on same page.
Please correct me if I misunderstood.
David, any objection?
On Wed, Dec 02, 2020 at 04:49:15PM +0100, Michal Hocko wrote:
> On Wed 02-12-20 10:14:41, David Hildenbrand wrote:
> > On 01.12.20 18:51, Minchan Kim wrote:
> > > There is a need for special HW to require bulk allocation of
> > > high-order pages. For example, 4800 * order-4 pages, which
> > > would be minimum, sometimes, it requires more.
> > >
> > > To meet the requirement, a option reserves 300M CMA area and
> > > requests the whole 300M contiguous memory. However, it doesn't
> > > work if even one of those pages in the range is long-term pinned
> > > directly or indirectly. The other option is to ask higher-order
> >
> > My latest knowledge is that pages in the CMA area are never long term
> > pinned.
> >
> > https://lore.kernel.org/lkml/20201123090129.GD27488@dhcp22.suse.cz/
> >
> > "gup already tries to deal with long term pins on CMA regions and migrate
> > to a non CMA region. Have a look at __gup_longterm_locked."
> >
> > We should rather identify ways how that is still possible and get rid of
> > them.
> >
> >
> > Now, short-term pinnings and PCP are other issues where
> > alloc_contig_range() could be improved (e.g., in contrast to a FAST
> > mode, a HARD mode which temporarily disables the PCP, ...).
>
> Agreed!
>
> > > size (e.g., 2M) than requested order(64K) repeatedly until driver
> > > could gather necessary amount of memory. Basically, this approach
> > > makes the allocation very slow due to cma_alloc's function
> > > slowness and it could be stuck on one of the pageblocks if it
> > > encounters unmigratable page.
> > >
> > > To solve the issue, this patch introduces cma_alloc_bulk.
> > >
> > > int cma_alloc_bulk(struct cma *cma, unsigned int align,
> > > bool fast, unsigned int order, size_t nr_requests,
> > > struct page **page_array, size_t *nr_allocated);
> > >
> > > Most parameters are same with cma_alloc but it additionally passes
> > > vector array to store allocated memory. What's different with cma_alloc
> > > is it will skip pageblocks without waiting/stopping if it has unmovable
> > > page so that API continues to scan other pageblocks to find requested
> > > order page.
> > >
> > > cma_alloc_bulk is best effort approach in that it skips some pageblocks
> > > if they have unmovable pages unlike cma_alloc. It doesn't need to be
> > > perfect from the beginning at the cost of performance. Thus, the API
> > > takes "bool fast parameter" which is propagated into alloc_contig_range to
> > > avoid significat overhead functions to inrecase CMA allocation success
> > > ratio(e.g., migration retrial, PCP, LRU draining per pageblock)
> > > at the cost of less allocation success ratio. If the caller couldn't
> > > allocate enough, they could call it with "false" to increase success ratio
> > > if they are okay to expense the overhead for the success ratio.
> >
> > Just so I understand what the idea is:
> >
> > alloc_contig_range() sometimes fails on CMA regions when trying to
> > allocate big chunks (e.g., 300M). Instead of tackling that issue, you
> > rather allocate plenty of small chunks, and make these small allocations
> > fail faster/ make the allocations less reliable. Correct?
> >
> > I don't really have a strong opinion on that. Giving up fast rather than
> > trying for longer sounds like a useful thing to have - but I wonder if
> > it's strictly necessary for the use case you describe.
> >
> > I'd like to hear Michals opinion on that.
>
> Well, what I can see is that this new interface is an antipatern to our
> allocation routines. We tend to control allocations by gfp mask yet you
> are introducing a bool parameter to make something faster... What that
> really means is rather arbitrary. Would it make more sense to teach
> cma_alloc resp. alloc_contig_range to recognize GFP_NOWAIT, GFP_NORETRY resp.
> GFP_RETRY_MAYFAIL instead?
If we use cma_alloc, that interface requires "allocate one big memory
chunk". IOW, return value is just struct page and expected that the page
is a big contiguos memory. That means it couldn't have a hole in the
range. However the idea here, what we asked is much smaller chunk rather
than a big contiguous memory so we could skip some of pages if they are
randomly pinned(long-term/short-term whatever) and search other pages
in the CMA area to avoid long stall. Thus, it couldn't work with exising
cma_alloc API with simple gfp_mak.
>
> I am not deeply familiar with the cma allocator so sorry for a
> potentially stupid question. Why does a bulk interface performs better
> than repeated calls to cma_alloc? Is this because a failure would help
> to move on to the next pfn range while a repeated call would have to
> deal with the same range?
Yub, true with other overheads(e.g., migration retrial, waiting writeback
PCP/LRU draining IPI)
>
> > > Signed-off-by: Minchan Kim <minchan(a)kernel.org>
> > > ---
> > > include/linux/cma.h | 5 ++
> > > include/linux/gfp.h | 2 +
> > > mm/cma.c | 126 ++++++++++++++++++++++++++++++++++++++++++--
> > > mm/page_alloc.c | 19 ++++---
> > > 4 files changed, 140 insertions(+), 12 deletions(-)
> > >
> --
> Michal Hocko
> SUSE Labs
On 02.12.20 16:49, Michal Hocko wrote:
> On Wed 02-12-20 10:14:41, David Hildenbrand wrote:
>> On 01.12.20 18:51, Minchan Kim wrote:
>>> There is a need for special HW to require bulk allocation of
>>> high-order pages. For example, 4800 * order-4 pages, which
>>> would be minimum, sometimes, it requires more.
>>>
>>> To meet the requirement, a option reserves 300M CMA area and
>>> requests the whole 300M contiguous memory. However, it doesn't
>>> work if even one of those pages in the range is long-term pinned
>>> directly or indirectly. The other option is to ask higher-order
>>
>> My latest knowledge is that pages in the CMA area are never long term
>> pinned.
>>
>> https://lore.kernel.org/lkml/20201123090129.GD27488@dhcp22.suse.cz/
>>
>> "gup already tries to deal with long term pins on CMA regions and migrate
>> to a non CMA region. Have a look at __gup_longterm_locked."
>>
>> We should rather identify ways how that is still possible and get rid of
>> them.
>>
>>
>> Now, short-term pinnings and PCP are other issues where
>> alloc_contig_range() could be improved (e.g., in contrast to a FAST
>> mode, a HARD mode which temporarily disables the PCP, ...).
>
> Agreed!
>
>>> size (e.g., 2M) than requested order(64K) repeatedly until driver
>>> could gather necessary amount of memory. Basically, this approach
>>> makes the allocation very slow due to cma_alloc's function
>>> slowness and it could be stuck on one of the pageblocks if it
>>> encounters unmigratable page.
>>>
>>> To solve the issue, this patch introduces cma_alloc_bulk.
>>>
>>> int cma_alloc_bulk(struct cma *cma, unsigned int align,
>>> bool fast, unsigned int order, size_t nr_requests,
>>> struct page **page_array, size_t *nr_allocated);
>>>
>>> Most parameters are same with cma_alloc but it additionally passes
>>> vector array to store allocated memory. What's different with cma_alloc
>>> is it will skip pageblocks without waiting/stopping if it has unmovable
>>> page so that API continues to scan other pageblocks to find requested
>>> order page.
>>>
>>> cma_alloc_bulk is best effort approach in that it skips some pageblocks
>>> if they have unmovable pages unlike cma_alloc. It doesn't need to be
>>> perfect from the beginning at the cost of performance. Thus, the API
>>> takes "bool fast parameter" which is propagated into alloc_contig_range to
>>> avoid significat overhead functions to inrecase CMA allocation success
>>> ratio(e.g., migration retrial, PCP, LRU draining per pageblock)
>>> at the cost of less allocation success ratio. If the caller couldn't
>>> allocate enough, they could call it with "false" to increase success ratio
>>> if they are okay to expense the overhead for the success ratio.
>>
>> Just so I understand what the idea is:
>>
>> alloc_contig_range() sometimes fails on CMA regions when trying to
>> allocate big chunks (e.g., 300M). Instead of tackling that issue, you
>> rather allocate plenty of small chunks, and make these small allocations
>> fail faster/ make the allocations less reliable. Correct?
>>
>> I don't really have a strong opinion on that. Giving up fast rather than
>> trying for longer sounds like a useful thing to have - but I wonder if
>> it's strictly necessary for the use case you describe.
>>
>> I'd like to hear Michals opinion on that.
>
> Well, what I can see is that this new interface is an antipatern to our
> allocation routines. We tend to control allocations by gfp mask yet you
> are introducing a bool parameter to make something faster... What that
> really means is rather arbitrary. Would it make more sense to teach
> cma_alloc resp. alloc_contig_range to recognize GFP_NOWAIT, GFP_NORETRY resp.
> GFP_RETRY_MAYFAIL instead?
Minchan did that before, but I disliked gluing things like "don't drain
lru, don't drain pcp" to GFP_NORETRY and shifting responsibility to the
user.
--
Thanks,
David / dhildenb
This patchset introduces a new dma heap, chunk heap that makes it
easy to perform the bulk allocation of high order pages.
It has been created to help optimize the 4K/8K HDR video playback
with secure DRM HW to protect contents on memory. The HW needs
physically contiguous memory chunks up to several hundred MB memory.
This patchset is against on next-20201130.
The patchset includes the following:
- cma_alloc_bulk API
- export dma-heap API to register kernel module dma heap.
- add chunk heap implementation.
* Since v1 -
https://lore.kernel.org/linux-mm/20201117181935.3613581-1-minchan@kernel.or…
* introduce alloc_contig_mode - David
* use default CMA instead of device tree - John
Hyesoo Yu (2):
dma-buf: add export symbol for dma-heap
dma-buf: heaps: add chunk heap to dmabuf heaps
Minchan Kim (2):
mm: introduce alloc_contig_mode
mm: introduce cma_alloc_bulk API
drivers/dma-buf/dma-heap.c | 2 +
drivers/dma-buf/heaps/Kconfig | 15 +
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/chunk_heap.c | 429 +++++++++++++++++++++++++++++
drivers/virtio/virtio_mem.c | 2 +-
include/linux/cma.h | 5 +
include/linux/gfp.h | 10 +-
kernel/dma/contiguous.c | 1 +
mm/cma.c | 134 ++++++++-
mm/page_alloc.c | 25 +-
10 files changed, 607 insertions(+), 17 deletions(-)
create mode 100644 drivers/dma-buf/heaps/chunk_heap.c
--
2.29.2.454.gaff20da3a2-goog