Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
On Tue, Jun 25, 2019 at 07:20:12AM +, Koenig, Christian wrote: > Am 24.06.19 um 16:41 schrieb Daniel Vetter: > > On Mon, Jun 24, 2019 at 03:58:00PM +0200, Christian König wrote: > >> Am 24.06.19 um 13:23 schrieb Koenig, Christian: > >>> Am 21.06.19 um 18:27 schrieb Daniel Vetter: > >>> > So I pondered a few ideas while working out: > > 1) We drop this filtering. Importer needs to keep track of all its > mappings and filter out invalidates that aren't for that specific > importer > (either because already invalidated, or not yet mapped, or whatever). > Feels fragile. > > [SNIP] > >>> [SNIP] > >>> > >>> I will take a moment and look into #1 as well, but I still don't see the > >>> need to change anything. > >> That turned out much cleaner than I thought it would be. Essentially it is > >> only a single extra line of code in amdgpu. > >> > >> Going to send that out as a patch set in a minute. > > Yeah I mean kinda expected that because: > > - everything's protected with ww_mutex anyway > > - importer needs to keep track of mappings anways > > So really all it needs to do is not be stupid and add the mapping it just > > created to its tracking while still holding the ww_mutex. Similar on > > invalidate/unmap. > > > > With that all we need is a huge note in the docs that importers need to > > keep track of their mappings and dtrt (with all the examples here spelled > > out in the appropriate kerneldoc). And then I'm happy :-) > > Should I also rename the invalidate callback into move_notify? Would > kind of make sense since we are not necessary directly invalidating > mappings. Hm maybe. I'll review the entire pile and probably reply with a docs patch anyway. It would help in making it clear you get the callback even when there's no mapping to invalidate for you ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
Am 24.06.19 um 16:41 schrieb Daniel Vetter: > On Mon, Jun 24, 2019 at 03:58:00PM +0200, Christian König wrote: >> Am 24.06.19 um 13:23 schrieb Koenig, Christian: >>> Am 21.06.19 um 18:27 schrieb Daniel Vetter: >>> So I pondered a few ideas while working out: 1) We drop this filtering. Importer needs to keep track of all its mappings and filter out invalidates that aren't for that specific importer (either because already invalidated, or not yet mapped, or whatever). Feels fragile. [SNIP] >>> [SNIP] >>> >>> I will take a moment and look into #1 as well, but I still don't see the >>> need to change anything. >> That turned out much cleaner than I thought it would be. Essentially it is >> only a single extra line of code in amdgpu. >> >> Going to send that out as a patch set in a minute. > Yeah I mean kinda expected that because: > - everything's protected with ww_mutex anyway > - importer needs to keep track of mappings anways > So really all it needs to do is not be stupid and add the mapping it just > created to its tracking while still holding the ww_mutex. Similar on > invalidate/unmap. > > With that all we need is a huge note in the docs that importers need to > keep track of their mappings and dtrt (with all the examples here spelled > out in the appropriate kerneldoc). And then I'm happy :-) Should I also rename the invalidate callback into move_notify? Would kind of make sense since we are not necessary directly invalidating mappings. Christian. > > Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
On Mon, Jun 24, 2019 at 03:58:00PM +0200, Christian König wrote: > Am 24.06.19 um 13:23 schrieb Koenig, Christian: > > Am 21.06.19 um 18:27 schrieb Daniel Vetter: > > > > > So I pondered a few ideas while working out: > > > > > > 1) We drop this filtering. Importer needs to keep track of all its > > > mappings and filter out invalidates that aren't for that specific importer > > > (either because already invalidated, or not yet mapped, or whatever). > > > Feels fragile. > > > > > > [SNIP] > > [SNIP] > > > > I will take a moment and look into #1 as well, but I still don't see the > > need to change anything. > > That turned out much cleaner than I thought it would be. Essentially it is > only a single extra line of code in amdgpu. > > Going to send that out as a patch set in a minute. Yeah I mean kinda expected that because: - everything's protected with ww_mutex anyway - importer needs to keep track of mappings anways So really all it needs to do is not be stupid and add the mapping it just created to its tracking while still holding the ww_mutex. Similar on invalidate/unmap. With that all we need is a huge note in the docs that importers need to keep track of their mappings and dtrt (with all the examples here spelled out in the appropriate kerneldoc). And then I'm happy :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
On Mon, Jun 24, 2019 at 11:23:34AM +, Koenig, Christian wrote: > Am 21.06.19 um 18:27 schrieb Daniel Vetter: > >>> Your scenario here is new, and iirc my suggestion back then was to > >>> count the number of pending mappings so you don't go around calling > >>> ->invalidate on mappings that don't exist. > >> Well the key point is we don't call invalidate on mappings, but we call > >> invalidate on attachments. > >> > >> When the invalidate on an attachment is received all the importer should at > >> least start to tear down all mappings. > > Hm, so either we invalidate mappings instead (pretty big change for > > dma-buf, but maybe worth it). Or importers need to deal with invalidate on > > stuff they're don't even have mapped anywhere anyway. > > I actually I don't see a problem with this, but see below. > > >> [SNIP] > >>> - your scenario, where you call ->invalidate on an attachment which > >>> doesn't have a mapping. I'll call that very lazy accounting, feels > >>> like a bug :-) It's also very easy to fix by keeping track who > >>> actually has a mapping, and then you fix it everywhere, not just for > >>> the specific case of a recursion into the same caller. > >> Yeah, exactly. Unfortunately it's not so easy to handle as just a counter. > >> > >> When somebody unmaps a mapping you need to know if that is already > >> invalidated or not. And this requires tracking of each mapping. > > Yeah we'd need to track mappings. Well, someone has to track mappings, and > > atm it seems to be a mix of both importer and exporter (and dma-buf.c). > > Maybe I'm missing something, but I don't see the mix? > > Only the importer is responsible to tracking mappings, e.g. the importer > calls dma_buf_map_attachment() when it needs a mapping and calls > dma_buf_unmap_attachment() when it is done with the mapping. > > In between those two neither the exporter nor the DMA-buf cares about > what mappings currently exist. And apart from debugging I actually don't > see a reason why they should. Atm importer has to track which mappings it actually has. Plus dma-buf.c also tracks that, somehow, with your recursion-preventation code. So that's the mix. > >> [SNIP] > >>> But I guess there's other fixes too possible. > >>> > >>> Either way none of this is about recursion, I think the recursive case > >>> is simply the one where you've hit this already. Drivers will have to > >>> handle all these additional ->invalidates no matter what with your > >>> current proposal. After all the point here is that the exporter can > >>> move the buffers around whenever it feels like, for whatever reasons. > >> The recursion case is still perfectly valid. In the importer I need to > >> ignore invalidations which are caused by creating a mapping. > >> > >> Otherwise it is perfectly possible that we invalidate a mapping because of > >> its creation which will result in creating a new one > >> > >> So even if you fix up your mapping case, you absolutely still need this to > >> prevent recursion :) > > Hm, but if we stop tracking attachments and instead start tracking > > mappings, then how is that possible: > > Yeah, but why should we do this? I don't see a benefit here. Importers > just create/destroy mappings as they need them. > > > 1. importer has no mappings > > 2. importer creates attachment. still no mapping > > 3. importer calls dma_buf_attach_map_sg, still no mapping at this point > > 4. we call into the exporter implementation. still no mapping > > 5. exporter does whatever it does. still no mapping > > 6. exporter finishes. conceptually from the dma-buf pov, _this_ is where > > the mapping starts to exist. > > 7. invalidates (hey the exporter maybe changed its mind!) are totally > > fine, and will be serialized with ww_mutex. > > > > So I kinda don understand why the exporter here is allowed to call > > invalidate too early (the mapping doesn't exist yet from dma-buf pov), and > > dma-buf needs to filter it out. > > > > But anywhere else where we might call ->invalidate and there's not yet a > > mapping (again purely from dma-buf pov), there the importer is supposed to > > do the filter. > > Maybe this becomes clearer if we call the callback "moved" instead of > "invalidated"? > > I mean this is actually all about the exporter informing the importer > that the DMA-buf in question is moving to a new location. > > That we need to create a new mapping and destroy the old one at some > point is an implementation detail on the importer. > > I mean the long term idea is to use this for notification that a buffer > is moving inside the same driver as well. And in this particular case I > actually don't think that we would create mappings at all. Thinking more > about it this is actually a really good argument to favor the > implementation as it is currently. > > > Someone needs to keep track of all this, and I want clear > > responsibilities. What they are exactly is not that important. > > Clear
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
Am 24.06.19 um 13:23 schrieb Koenig, Christian: Am 21.06.19 um 18:27 schrieb Daniel Vetter: So I pondered a few ideas while working out: 1) We drop this filtering. Importer needs to keep track of all its mappings and filter out invalidates that aren't for that specific importer (either because already invalidated, or not yet mapped, or whatever). Feels fragile. [SNIP] [SNIP] I will take a moment and look into #1 as well, but I still don't see the need to change anything. That turned out much cleaner than I thought it would be. Essentially it is only a single extra line of code in amdgpu. Going to send that out as a patch set in a minute. Christian. Christian. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
Am 21.06.19 um 18:27 schrieb Daniel Vetter: >>> Your scenario here is new, and iirc my suggestion back then was to >>> count the number of pending mappings so you don't go around calling >>> ->invalidate on mappings that don't exist. >> Well the key point is we don't call invalidate on mappings, but we call >> invalidate on attachments. >> >> When the invalidate on an attachment is received all the importer should at >> least start to tear down all mappings. > Hm, so either we invalidate mappings instead (pretty big change for > dma-buf, but maybe worth it). Or importers need to deal with invalidate on > stuff they're don't even have mapped anywhere anyway. I actually I don't see a problem with this, but see below. >> [SNIP] >>> - your scenario, where you call ->invalidate on an attachment which >>> doesn't have a mapping. I'll call that very lazy accounting, feels >>> like a bug :-) It's also very easy to fix by keeping track who >>> actually has a mapping, and then you fix it everywhere, not just for >>> the specific case of a recursion into the same caller. >> Yeah, exactly. Unfortunately it's not so easy to handle as just a counter. >> >> When somebody unmaps a mapping you need to know if that is already >> invalidated or not. And this requires tracking of each mapping. > Yeah we'd need to track mappings. Well, someone has to track mappings, and > atm it seems to be a mix of both importer and exporter (and dma-buf.c). Maybe I'm missing something, but I don't see the mix? Only the importer is responsible to tracking mappings, e.g. the importer calls dma_buf_map_attachment() when it needs a mapping and calls dma_buf_unmap_attachment() when it is done with the mapping. In between those two neither the exporter nor the DMA-buf cares about what mappings currently exist. And apart from debugging I actually don't see a reason why they should. >> [SNIP] >>> But I guess there's other fixes too possible. >>> >>> Either way none of this is about recursion, I think the recursive case >>> is simply the one where you've hit this already. Drivers will have to >>> handle all these additional ->invalidates no matter what with your >>> current proposal. After all the point here is that the exporter can >>> move the buffers around whenever it feels like, for whatever reasons. >> The recursion case is still perfectly valid. In the importer I need to >> ignore invalidations which are caused by creating a mapping. >> >> Otherwise it is perfectly possible that we invalidate a mapping because of >> its creation which will result in creating a new one >> >> So even if you fix up your mapping case, you absolutely still need this to >> prevent recursion :) > Hm, but if we stop tracking attachments and instead start tracking > mappings, then how is that possible: Yeah, but why should we do this? I don't see a benefit here. Importers just create/destroy mappings as they need them. > 1. importer has no mappings > 2. importer creates attachment. still no mapping > 3. importer calls dma_buf_attach_map_sg, still no mapping at this point > 4. we call into the exporter implementation. still no mapping > 5. exporter does whatever it does. still no mapping > 6. exporter finishes. conceptually from the dma-buf pov, _this_ is where > the mapping starts to exist. > 7. invalidates (hey the exporter maybe changed its mind!) are totally > fine, and will be serialized with ww_mutex. > > So I kinda don understand why the exporter here is allowed to call > invalidate too early (the mapping doesn't exist yet from dma-buf pov), and > dma-buf needs to filter it out. > > But anywhere else where we might call ->invalidate and there's not yet a > mapping (again purely from dma-buf pov), there the importer is supposed to > do the filter. Maybe this becomes clearer if we call the callback "moved" instead of "invalidated"? I mean this is actually all about the exporter informing the importer that the DMA-buf in question is moving to a new location. That we need to create a new mapping and destroy the old one at some point is an implementation detail on the importer. I mean the long term idea is to use this for notification that a buffer is moving inside the same driver as well. And in this particular case I actually don't think that we would create mappings at all. Thinking more about it this is actually a really good argument to favor the implementation as it is currently. > Someone needs to keep track of all this, and I want clear > responsibilities. What they are exactly is not that important. Clear responsibilities is indeed a good idea. >>> We could also combine the last two with some helpers, e.g. if your >>> exporter really expects importers to delay the unmap until it's no >>> longer in use, then we could do a small helper which puts all these >>> unmaps onto a list with a worker. But I think you want to integrate >>> that into your exporters lru management directly. >>> So this is just the most defensive thing
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
On Fri, Jun 21, 2019 at 02:06:54PM +0200, Christian König wrote: > Am 21.06.19 um 12:32 schrieb Daniel Vetter: > > On Fri, Jun 21, 2019 at 11:55 AM Christian König > > wrote: > > > Am 21.06.19 um 11:20 schrieb Daniel Vetter: > > > > On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote: > > > > [SNIP] > > > > Imo the below semantics would be much cleaner: > > > > > > > > - invalidate may add new fences > > > > - invalidate _must_ unmap its mappings > > > > - an unmap must wait for current fences before the mapping can be > > > > released. > > > > > > > > Imo there's no reason why unmap is special, and the only thing where we > > > > don't use fences to gate access to resources/memory when it's in the > > > > process of getting moved around. > > > Well in general I want to avoid waiting for fences as much as possible. > > > But the key point here is that this actually won't help with the problem > > > I'm trying to solve. > > The point of using fences is not to wait on them. I mean if you have > > the shadow ttm bo on the lru you also don't wait for that fence to > > retire before you insert the shadow bo onto the lru. You don't even > > wait when you try to use that memory again, you just pipeline more > > stuff on top. > > Correct. > > Ok, if I understand it correctly your suggestion is to move the > responsibility to delay destruction of mappings until they are no longer > used from the importer to the exporter based on the fences of the > reservation object. > > I seriously don't think that this is a good idea because you need to move > the tracking who is using which mapping from the importer to the exporter as > well. So duplicating quite a bunch of housekeeping. > > On the other hand that we have this house keeping in the importer because we > get it for free from TTM. But I can't think of a way other memory management > backends would do this without keeping the sg table around either. > > > In the end it will be the exact same amount of fences and waiting in > > both solutions. One just leaks less implementationt details (at least > > in my opinion) across the dma-buf border. > > I agree that leaking implementation details over the DMA-buf border is a bad > idea. > > But I can assure you that this has absolutely nothing todo with the ghost > object handling of TTM. ghost objects doesn't even receive an invalidation, > they are just a possible implementation of the delayed destruction of sg > tables. > > > > > btw this is like the 2nd or 3rd time I'm typing this, haven't seen your > > > > thoughts on this yet. > > > Yeah, and I'm responding for the 3rd time now that you are > > > misunderstanding why we need this here :) > > > > > > Maybe I can make that clear with an example: > > > > > > 1. You got a sharing between device A (exporter) and B (importer) which > > > uses P2P. > > > > > > 2. Now device C (importer) comes along and wants to use the DMA-buf > > > object as well. > > > > > > 3. The handling now figures out that we can't do P2P between device A > > > and device C (for whatever reason). > > > > > > 4. The map_attachment implementation in device driver A doesn't want to > > > fail with -EBUSY and migrates the DMA-buf somewhere where both device A > > > and device C can access it. > > > > > > 5. This migration will result in sending an invalidation event around. > > > And here it doesn't make sense to send this invalidation event to device > > > C, because we know that device C is actually causing this event and > > > doesn't have a valid mapping. > > Hm I thought the last time around there was a different scenario, with > > just one importer: > > > > - importer has a mapping, gets an ->invalidate call. > > - importer arranges for the mappings/usage to get torn down, maybe > > updating fences, all from ->invalidate. But the mapping itself wont > > disappear. > > - exporter moves buffer to new places (for whatever reasons it felt > > that was the thing to do). > > - importer does another execbuf, the exporter needs to move the buffer > > back. Again it calls ->invalidate, but on a mapping it already has > > called ->invalidate on, and to prevent that silliness we take the > > importer temporary off the list. > > Mhm, strange I don't remember giving this explanation. It also doesn't make > to much sense, but see below. Yeah maybe I mixed things up somewhere. I guess you started with the first scenario, I replied with "why don't we track this in the exporter or dma-buf.c then?" and then the thread died out or something. > > > Your scenario here is new, and iirc my suggestion back then was to > > count the number of pending mappings so you don't go around calling > > ->invalidate on mappings that don't exist. > > Well the key point is we don't call invalidate on mappings, but we call > invalidate on attachments. > > When the invalidate on an attachment is received all the importer should at > least start to tear down all mappings. Hm, so either we
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
Am 21.06.19 um 12:32 schrieb Daniel Vetter: On Fri, Jun 21, 2019 at 11:55 AM Christian König wrote: Am 21.06.19 um 11:20 schrieb Daniel Vetter: On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote: [SNIP] Imo the below semantics would be much cleaner: - invalidate may add new fences - invalidate _must_ unmap its mappings - an unmap must wait for current fences before the mapping can be released. Imo there's no reason why unmap is special, and the only thing where we don't use fences to gate access to resources/memory when it's in the process of getting moved around. Well in general I want to avoid waiting for fences as much as possible. But the key point here is that this actually won't help with the problem I'm trying to solve. The point of using fences is not to wait on them. I mean if you have the shadow ttm bo on the lru you also don't wait for that fence to retire before you insert the shadow bo onto the lru. You don't even wait when you try to use that memory again, you just pipeline more stuff on top. Correct. Ok, if I understand it correctly your suggestion is to move the responsibility to delay destruction of mappings until they are no longer used from the importer to the exporter based on the fences of the reservation object. I seriously don't think that this is a good idea because you need to move the tracking who is using which mapping from the importer to the exporter as well. So duplicating quite a bunch of housekeeping. On the other hand that we have this house keeping in the importer because we get it for free from TTM. But I can't think of a way other memory management backends would do this without keeping the sg table around either. In the end it will be the exact same amount of fences and waiting in both solutions. One just leaks less implementationt details (at least in my opinion) across the dma-buf border. I agree that leaking implementation details over the DMA-buf border is a bad idea. But I can assure you that this has absolutely nothing todo with the ghost object handling of TTM. ghost objects doesn't even receive an invalidation, they are just a possible implementation of the delayed destruction of sg tables. btw this is like the 2nd or 3rd time I'm typing this, haven't seen your thoughts on this yet. Yeah, and I'm responding for the 3rd time now that you are misunderstanding why we need this here :) Maybe I can make that clear with an example: 1. You got a sharing between device A (exporter) and B (importer) which uses P2P. 2. Now device C (importer) comes along and wants to use the DMA-buf object as well. 3. The handling now figures out that we can't do P2P between device A and device C (for whatever reason). 4. The map_attachment implementation in device driver A doesn't want to fail with -EBUSY and migrates the DMA-buf somewhere where both device A and device C can access it. 5. This migration will result in sending an invalidation event around. And here it doesn't make sense to send this invalidation event to device C, because we know that device C is actually causing this event and doesn't have a valid mapping. Hm I thought the last time around there was a different scenario, with just one importer: - importer has a mapping, gets an ->invalidate call. - importer arranges for the mappings/usage to get torn down, maybe updating fences, all from ->invalidate. But the mapping itself wont disappear. - exporter moves buffer to new places (for whatever reasons it felt that was the thing to do). - importer does another execbuf, the exporter needs to move the buffer back. Again it calls ->invalidate, but on a mapping it already has called ->invalidate on, and to prevent that silliness we take the importer temporary off the list. Mhm, strange I don't remember giving this explanation. It also doesn't make to much sense, but see below. Your scenario here is new, and iirc my suggestion back then was to count the number of pending mappings so you don't go around calling ->invalidate on mappings that don't exist. Well the key point is we don't call invalidate on mappings, but we call invalidate on attachments. When the invalidate on an attachment is received all the importer should at least start to tear down all mappings. But even if you fix your scenario here there's still the issue that we can receive invalidates on a mapping we've already torn down and which is on the process of disappearing. That's kinda the part I don't think is great semantics. Yeah, that is a rather valid point. Currently it is perfectly valid to receive an invalidation when you don't even have any mappings at all. But this is intentional, because otherwise I would need to move the housekeeping which mappings are currently made from the importer to the exporter. And as explained above that would essentially mean double housekeeping. [SNIP] The reason I don't have that on unmap is that I think migrating things on unmap
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
On Fri, Jun 21, 2019 at 11:55 AM Christian König
wrote:
>
> Am 21.06.19 um 11:20 schrieb Daniel Vetter:
> > On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
> >> On the exporter side we add optional explicit pinning callbacks. If those
> >> callbacks are implemented the framework no longer caches sg tables and the
> >> map/unmap callbacks are always called with the lock of the reservation
> >> object
> >> held.
> >>
> >> On the importer side we add an optional invalidate callback. This callback
> >> is
> >> used by the exporter to inform the importers that their mappings should be
> >> destroyed as soon as possible.
> >>
> >> This allows the exporter to provide the mappings without the need to pin
> >> the backing store.
> >>
> >> v2: don't try to invalidate mappings when the callback is NULL,
> >> lock the reservation obj while using the attachments,
> >> add helper to set the callback
> >> v3: move flag for invalidation support into the DMA-buf,
> >> use new attach_info structure to set the callback
> >> v4: use importer_priv field instead of mangling exporter priv.
> >> v5: drop invalidation_supported flag
> >> v6: squash together with pin/unpin changes
> >> v7: pin/unpin takes an attachment now
> >> v8: nuke dma_buf_attachment_(map|unmap)_locked,
> >> everything is now handled backward compatible
> >> v9: always cache when export/importer don't agree on dynamic handling
> >> v10: minimal style cleanup
> >>
> >> Signed-off-by: Christian König
> >> ---
> >> drivers/dma-buf/dma-buf.c | 188 --
> >> include/linux/dma-buf.h | 109 --
> >> 2 files changed, 283 insertions(+), 14 deletions(-)
> >>
> >> [SNIP]
> >> +if (dma_buf_attachment_is_dynamic(attach)) {
> >> +reservation_object_assert_held(attach->dmabuf->resv);
> >> +
> >> +/*
> >> + * Mapping a DMA-buf can trigger its invalidation, prevent
> >> + * sending this event to the caller by temporary removing
> >> + * this attachment from the list.
> >> + */
> >> +list_del(>node);
> > I'm still hung up about this, that still feels like leaking random ttm
> > implementation details into the dma-buf interfaces. And it's asymmetric:
> >
> > - When acquiring a buffer mapping (whether p2p or system memory sg or
> >whatever) we always have to wait for pending fences before we can access
> >the buffer. At least for full dynamic dma-buf access.
> >
> > - Same is true when dropping a mapping: We could drop the mapping
> >immediately, but only actually release it when that fence has signalled.
> >Then this hack here wouldn't be necessary.
> >
> > It feels a bit like this is just an artifact of how ttm currently does bo
> > moves with the shadow bo. There's other ways to fix that, you could just
> > have a memory manager reservation of a given range or whatever and a
> > release fence from when it's actually good to use.
>
> No, that is for handling a completely different case :)
>
> >
> > Imo the below semantics would be much cleaner:
> >
> > - invalidate may add new fences
> > - invalidate _must_ unmap its mappings
> > - an unmap must wait for current fences before the mapping can be
> >released.
> >
> > Imo there's no reason why unmap is special, and the only thing where we
> > don't use fences to gate access to resources/memory when it's in the
> > process of getting moved around.
>
> Well in general I want to avoid waiting for fences as much as possible.
> But the key point here is that this actually won't help with the problem
> I'm trying to solve.
The point of using fences is not to wait on them. I mean if you have
the shadow ttm bo on the lru you also don't wait for that fence to
retire before you insert the shadow bo onto the lru. You don't even
wait when you try to use that memory again, you just pipeline more
stuff on top.
In the end it will be the exact same amount of fences and waiting in
both solutions. One just leaks less implementationt details (at least
in my opinion) across the dma-buf border.
> > btw this is like the 2nd or 3rd time I'm typing this, haven't seen your
> > thoughts on this yet.
>
> Yeah, and I'm responding for the 3rd time now that you are
> misunderstanding why we need this here :)
>
> Maybe I can make that clear with an example:
>
> 1. You got a sharing between device A (exporter) and B (importer) which
> uses P2P.
>
> 2. Now device C (importer) comes along and wants to use the DMA-buf
> object as well.
>
> 3. The handling now figures out that we can't do P2P between device A
> and device C (for whatever reason).
>
> 4. The map_attachment implementation in device driver A doesn't want to
> fail with -EBUSY and migrates the DMA-buf somewhere where both device A
> and device C can access it.
>
> 5. This migration will result in sending an invalidation event around.
> And here it doesn't make sense to send this invalidation
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
Am 21.06.19 um 11:20 schrieb Daniel Vetter:
On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called with the lock of the reservation object
held.
On the importer side we add an optional invalidate callback. This callback is
used by the exporter to inform the importers that their mappings should be
destroyed as soon as possible.
This allows the exporter to provide the mappings without the need to pin
the backing store.
v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
v6: squash together with pin/unpin changes
v7: pin/unpin takes an attachment now
v8: nuke dma_buf_attachment_(map|unmap)_locked,
everything is now handled backward compatible
v9: always cache when export/importer don't agree on dynamic handling
v10: minimal style cleanup
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 188 --
include/linux/dma-buf.h | 109 --
2 files changed, 283 insertions(+), 14 deletions(-)
[SNIP]
+ if (dma_buf_attachment_is_dynamic(attach)) {
+ reservation_object_assert_held(attach->dmabuf->resv);
+
+ /*
+* Mapping a DMA-buf can trigger its invalidation, prevent
+* sending this event to the caller by temporary removing
+* this attachment from the list.
+*/
+ list_del(>node);
I'm still hung up about this, that still feels like leaking random ttm
implementation details into the dma-buf interfaces. And it's asymmetric:
- When acquiring a buffer mapping (whether p2p or system memory sg or
whatever) we always have to wait for pending fences before we can access
the buffer. At least for full dynamic dma-buf access.
- Same is true when dropping a mapping: We could drop the mapping
immediately, but only actually release it when that fence has signalled.
Then this hack here wouldn't be necessary.
It feels a bit like this is just an artifact of how ttm currently does bo
moves with the shadow bo. There's other ways to fix that, you could just
have a memory manager reservation of a given range or whatever and a
release fence from when it's actually good to use.
No, that is for handling a completely different case :)
Imo the below semantics would be much cleaner:
- invalidate may add new fences
- invalidate _must_ unmap its mappings
- an unmap must wait for current fences before the mapping can be
released.
Imo there's no reason why unmap is special, and the only thing where we
don't use fences to gate access to resources/memory when it's in the
process of getting moved around.
Well in general I want to avoid waiting for fences as much as possible.
But the key point here is that this actually won't help with the problem
I'm trying to solve.
btw this is like the 2nd or 3rd time I'm typing this, haven't seen your
thoughts on this yet.
Yeah, and I'm responding for the 3rd time now that you are
misunderstanding why we need this here :)
Maybe I can make that clear with an example:
1. You got a sharing between device A (exporter) and B (importer) which
uses P2P.
2. Now device C (importer) comes along and wants to use the DMA-buf
object as well.
3. The handling now figures out that we can't do P2P between device A
and device C (for whatever reason).
4. The map_attachment implementation in device driver A doesn't want to
fail with -EBUSY and migrates the DMA-buf somewhere where both device A
and device C can access it.
5. This migration will result in sending an invalidation event around.
And here it doesn't make sense to send this invalidation event to device
C, because we know that device C is actually causing this event and
doesn't have a valid mapping.
One alternative would be to completely disallow buffer migration which
can cause invalidation in the drivers map_attachment call. But with
dynamic handling you definitely need to be able to migrate in the
map_attachment call for swapping evicted things back into a place where
they are accessible. So that would make it harder for drivers to get it
right.
Another alternative (and that's what I implemented initially) is to make
sure the driver calling map_attachment can handle invalidation events
re-entering itself while doing so. But then you add another tricky thing
for drivers to handle which could be done in the general code.
The reason I don't have that on unmap is that I think migrating things
on unmap doesn't
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
> On the exporter side we add optional explicit pinning callbacks. If those
> callbacks are implemented the framework no longer caches sg tables and the
> map/unmap callbacks are always called with the lock of the reservation object
> held.
>
> On the importer side we add an optional invalidate callback. This callback is
> used by the exporter to inform the importers that their mappings should be
> destroyed as soon as possible.
>
> This allows the exporter to provide the mappings without the need to pin
> the backing store.
>
> v2: don't try to invalidate mappings when the callback is NULL,
> lock the reservation obj while using the attachments,
> add helper to set the callback
> v3: move flag for invalidation support into the DMA-buf,
> use new attach_info structure to set the callback
> v4: use importer_priv field instead of mangling exporter priv.
> v5: drop invalidation_supported flag
> v6: squash together with pin/unpin changes
> v7: pin/unpin takes an attachment now
> v8: nuke dma_buf_attachment_(map|unmap)_locked,
> everything is now handled backward compatible
> v9: always cache when export/importer don't agree on dynamic handling
> v10: minimal style cleanup
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-buf.c | 188 --
> include/linux/dma-buf.h | 109 --
> 2 files changed, 283 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 6c15deb5d4ad..9c9c95a88655 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -531,6 +531,9 @@ struct dma_buf *dma_buf_export(const struct
> dma_buf_export_info *exp_info)
> return ERR_PTR(-EINVAL);
> }
>
> + if (WARN_ON(exp_info->ops->cache_sgt_mapping && exp_info->ops->pin))
> + return ERR_PTR(-EINVAL);
> +
> if (!try_module_get(exp_info->owner))
> return ERR_PTR(-ENOENT);
>
> @@ -651,10 +654,12 @@ void dma_buf_put(struct dma_buf *dmabuf)
> EXPORT_SYMBOL_GPL(dma_buf_put);
>
> /**
> - * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
> + * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list;
> optionally,
> * calls attach() of dma_buf_ops to allow device-specific attach
> functionality
> - * @dmabuf: [in]buffer to attach device to.
> - * @dev: [in]device to be attached.
> + * @dmabuf: [in]buffer to attach device to.
> + * @dev: [in]device to be attached.
> + * @importer_ops [in]importer operations for the attachment
> + * @importer_priv[in]importer private pointer for the attachment
> *
> * Returns struct dma_buf_attachment pointer for this attachment. Attachments
> * must be cleaned up by calling dma_buf_detach().
> @@ -668,8 +673,10 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
> * accessible to @dev, and cannot be moved to a more suitable place. This is
> * indicated with the error code -EBUSY.
> */
> -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> - struct device *dev)
> +struct dma_buf_attachment *
> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> +const struct dma_buf_attach_ops *importer_ops,
> +void *importer_priv)
> {
> struct dma_buf_attachment *attach;
> int ret;
> @@ -683,6 +690,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
> *dmabuf,
>
> attach->dev = dev;
> attach->dmabuf = dmabuf;
> + attach->importer_ops = importer_ops;
> + attach->importer_priv = importer_priv;
>
> mutex_lock(>lock);
>
> @@ -691,16 +700,72 @@ struct dma_buf_attachment *dma_buf_attach(struct
> dma_buf *dmabuf,
> if (ret)
> goto err_attach;
> }
> + reservation_object_lock(dmabuf->resv, NULL);
> list_add(>node, >attachments);
> + reservation_object_unlock(dmabuf->resv);
>
> mutex_unlock(>lock);
>
> + /* When either the importer or the exporter can't handle dynamic
> + * mappings we cache the mapping here to avoid issues with the
> + * reservation object lock.
> + */
> + if (dma_buf_attachment_is_dynamic(attach) !=
> + dma_buf_is_dynamic(dmabuf)) {
> + struct sg_table *sgt;
> +
> + if (dma_buf_is_dynamic(attach->dmabuf)) {
> + reservation_object_lock(attach->dmabuf->resv, NULL);
> + ret = dma_buf_pin(attach);
> + if (ret)
> + goto err_unlock;
> + }
> +
> + sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
> + if (!sgt)
> + sgt = ERR_PTR(-ENOMEM);
> + if (IS_ERR(sgt)) {
> + ret = PTR_ERR(sgt);
> +
[Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called with the lock of the reservation object
held.
On the importer side we add an optional invalidate callback. This callback is
used by the exporter to inform the importers that their mappings should be
destroyed as soon as possible.
This allows the exporter to provide the mappings without the need to pin
the backing store.
v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
v6: squash together with pin/unpin changes
v7: pin/unpin takes an attachment now
v8: nuke dma_buf_attachment_(map|unmap)_locked,
everything is now handled backward compatible
v9: always cache when export/importer don't agree on dynamic handling
v10: minimal style cleanup
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 188 --
include/linux/dma-buf.h | 109 --
2 files changed, 283 insertions(+), 14 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 6c15deb5d4ad..9c9c95a88655 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -531,6 +531,9 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
+ if (WARN_ON(exp_info->ops->cache_sgt_mapping && exp_info->ops->pin))
+ return ERR_PTR(-EINVAL);
+
if (!try_module_get(exp_info->owner))
return ERR_PTR(-ENOENT);
@@ -651,10 +654,12 @@ void dma_buf_put(struct dma_buf *dmabuf)
EXPORT_SYMBOL_GPL(dma_buf_put);
/**
- * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
+ * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list;
optionally,
* calls attach() of dma_buf_ops to allow device-specific attach functionality
- * @dmabuf:[in]buffer to attach device to.
- * @dev: [in]device to be attached.
+ * @dmabuf:[in]buffer to attach device to.
+ * @dev: [in]device to be attached.
+ * @importer_ops [in]importer operations for the attachment
+ * @importer_priv [in]importer private pointer for the attachment
*
* Returns struct dma_buf_attachment pointer for this attachment. Attachments
* must be cleaned up by calling dma_buf_detach().
@@ -668,8 +673,10 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* accessible to @dev, and cannot be moved to a more suitable place. This is
* indicated with the error code -EBUSY.
*/
-struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
+struct dma_buf_attachment *
+dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
+ const struct dma_buf_attach_ops *importer_ops,
+ void *importer_priv)
{
struct dma_buf_attachment *attach;
int ret;
@@ -683,6 +690,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
attach->dev = dev;
attach->dmabuf = dmabuf;
+ attach->importer_ops = importer_ops;
+ attach->importer_priv = importer_priv;
mutex_lock(>lock);
@@ -691,16 +700,72 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
if (ret)
goto err_attach;
}
+ reservation_object_lock(dmabuf->resv, NULL);
list_add(>node, >attachments);
+ reservation_object_unlock(dmabuf->resv);
mutex_unlock(>lock);
+ /* When either the importer or the exporter can't handle dynamic
+* mappings we cache the mapping here to avoid issues with the
+* reservation object lock.
+*/
+ if (dma_buf_attachment_is_dynamic(attach) !=
+ dma_buf_is_dynamic(dmabuf)) {
+ struct sg_table *sgt;
+
+ if (dma_buf_is_dynamic(attach->dmabuf)) {
+ reservation_object_lock(attach->dmabuf->resv, NULL);
+ ret = dma_buf_pin(attach);
+ if (ret)
+ goto err_unlock;
+ }
+
+ sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
+ if (!sgt)
+ sgt = ERR_PTR(-ENOMEM);
+ if (IS_ERR(sgt)) {
+ ret = PTR_ERR(sgt);
+ goto err_unpin;
+ }
+ if (dma_buf_is_dynamic(attach->dmabuf))
+ reservation_object_unlock(attach->dmabuf->resv);
+
[Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called with the lock of the reservation object
held.
On the importer side we add an optional invalidate callback. This callback is
used by the exporter to inform the importers that their mappings should be
destroyed as soon as possible.
This allows the exporter to provide the mappings without the need to pin
the backing store.
v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
v6: squash together with pin/unpin changes
v7: pin/unpin takes an attachment now
v8: nuke dma_buf_attachment_(map|unmap)_locked,
everything is now handled backward compatible
v9: always cache when export/importer don't agree on dynamic handling
v10: minimal style cleanup
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 188 --
include/linux/dma-buf.h | 109 --
2 files changed, 283 insertions(+), 14 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index a2d34c6b80a5..f756870ba509 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -409,6 +409,9 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
+ if (WARN_ON(exp_info->ops->cache_sgt_mapping && exp_info->ops->pin))
+ return ERR_PTR(-EINVAL);
+
if (!try_module_get(exp_info->owner))
return ERR_PTR(-ENOENT);
@@ -530,10 +533,12 @@ void dma_buf_put(struct dma_buf *dmabuf)
EXPORT_SYMBOL_GPL(dma_buf_put);
/**
- * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
+ * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list;
optionally,
* calls attach() of dma_buf_ops to allow device-specific attach functionality
- * @dmabuf:[in]buffer to attach device to.
- * @dev: [in]device to be attached.
+ * @dmabuf:[in]buffer to attach device to.
+ * @dev: [in]device to be attached.
+ * @importer_ops [in]importer operations for the attachment
+ * @importer_priv [in]importer private pointer for the attachment
*
* Returns struct dma_buf_attachment pointer for this attachment. Attachments
* must be cleaned up by calling dma_buf_detach().
@@ -547,8 +552,10 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* accessible to @dev, and cannot be moved to a more suitable place. This is
* indicated with the error code -EBUSY.
*/
-struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
+struct dma_buf_attachment *
+dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
+ const struct dma_buf_attach_ops *importer_ops,
+ void *importer_priv)
{
struct dma_buf_attachment *attach;
int ret;
@@ -562,6 +569,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
attach->dev = dev;
attach->dmabuf = dmabuf;
+ attach->importer_ops = importer_ops;
+ attach->importer_priv = importer_priv;
mutex_lock(>lock);
@@ -570,16 +579,72 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
if (ret)
goto err_attach;
}
+ reservation_object_lock(dmabuf->resv, NULL);
list_add(>node, >attachments);
+ reservation_object_unlock(dmabuf->resv);
mutex_unlock(>lock);
+ /* When either the importer or the exporter can't handle dynamic
+* mappings we cache the mapping here to avoid issues with the
+* reservation object lock.
+*/
+ if (dma_buf_attachment_is_dynamic(attach) !=
+ dma_buf_is_dynamic(dmabuf)) {
+ struct sg_table *sgt;
+
+ if (dma_buf_is_dynamic(attach->dmabuf)) {
+ reservation_object_lock(attach->dmabuf->resv, NULL);
+ ret = dma_buf_pin(attach);
+ if (ret)
+ goto err_unlock;
+ }
+
+ sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
+ if (!sgt)
+ sgt = ERR_PTR(-ENOMEM);
+ if (IS_ERR(sgt)) {
+ ret = PTR_ERR(sgt);
+ goto err_unpin;
+ }
+ if (dma_buf_is_dynamic(attach->dmabuf))
+ reservation_object_unlock(attach->dmabuf->resv);
+
