* drm: Why shmem? @ 2017-08-28 18:44 Noralf Trønnes 2017-08-28 20:40 ` Eric Anholt 2017-08-28 20:45 ` Daniel Vetter 0 siblings, 2 replies; 9+ messages in thread From: Noralf Trønnes @ 2017-08-28 18:44 UTC (permalink / raw) To: dri-devel Hi, Currently I'm using the cma library with tinydrm because it was so simple to use even though I have to work around the fact that reads are uncached. A bigger problem that I have become aware of, is that it restricts the dma buffers it can import since they have to be continous. So I looked to udl and it uses shmem. Fine, let's make a shmem gem library similar to the cma library. Now I have done so and have started to think about the DOC: section, explaining what the library does. And I'm stuck, what's the benefit of using shmem compared to just using alloc_page()? Noralf. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: drm: Why shmem? 2017-08-28 18:44 drm: Why shmem? Noralf Trønnes @ 2017-08-28 20:40 ` Eric Anholt 2017-08-28 20:45 ` Daniel Vetter 1 sibling, 0 replies; 9+ messages in thread From: Eric Anholt @ 2017-08-28 20:40 UTC (permalink / raw) To: Noralf Trønnes, dri-devel [-- Attachment #1.1: Type: text/plain, Size: 778 bytes --] Noralf Trønnes <noralf@tronnes.org> writes: > Hi, > > Currently I'm using the cma library with tinydrm because it was so > simple to use even though I have to work around the fact that reads are > uncached. A bigger problem that I have become aware of, is that it > restricts the dma buffers it can import since they have to be continous. > > So I looked to udl and it uses shmem. Fine, let's make a shmem gem > library similar to the cma library. > > Now I have done so and have started to think about the DOC: section, > explaining what the library does. And I'm stuck, what's the benefit of > using shmem compared to just using alloc_page()? Using shmem means that, when the buffer isn't pinned for DMA usage by the device, the pages can be swapped out. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: drm: Why shmem? 2017-08-28 18:44 drm: Why shmem? Noralf Trønnes 2017-08-28 20:40 ` Eric Anholt @ 2017-08-28 20:45 ` Daniel Vetter 2017-08-29 17:40 ` Eric Anholt 1 sibling, 1 reply; 9+ messages in thread From: Daniel Vetter @ 2017-08-28 20:45 UTC (permalink / raw) To: Noralf Trønnes; +Cc: dri-devel On Mon, Aug 28, 2017 at 8:44 PM, Noralf Trønnes <noralf@tronnes.org> wrote: > Hi, > > Currently I'm using the cma library with tinydrm because it was so > simple to use even though I have to work around the fact that reads are > uncached. A bigger problem that I have become aware of, is that it > restricts the dma buffers it can import since they have to be continous. > > So I looked to udl and it uses shmem. Fine, let's make a shmem gem > library similar to the cma library. > > Now I have done so and have started to think about the DOC: section, > explaining what the library does. And I'm stuck, what's the benefit of > using shmem compared to just using alloc_page()? Gives you swapping (and eventually maybe even migration) since there's a real filesystem behind it. Atm this only works if you register a shrinker callback, which for display drivers is a bit overkill. See i915 or msm for examples (or ttm, if you want an entire fancy framework), and git grep shrinker -- drivers/gpu. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: drm: Why shmem? 2017-08-28 20:45 ` Daniel Vetter @ 2017-08-29 17:40 ` Eric Anholt 2017-08-30 7:40 ` Daniel Vetter 0 siblings, 1 reply; 9+ messages in thread From: Eric Anholt @ 2017-08-29 17:40 UTC (permalink / raw) To: Daniel Vetter, Noralf Trønnes; +Cc: dri-devel [-- Attachment #1.1: Type: text/plain, Size: 1349 bytes --] Daniel Vetter <daniel@ffwll.ch> writes: > On Mon, Aug 28, 2017 at 8:44 PM, Noralf Trønnes <noralf@tronnes.org> wrote: >> Hi, >> >> Currently I'm using the cma library with tinydrm because it was so >> simple to use even though I have to work around the fact that reads are >> uncached. A bigger problem that I have become aware of, is that it >> restricts the dma buffers it can import since they have to be continous. >> >> So I looked to udl and it uses shmem. Fine, let's make a shmem gem >> library similar to the cma library. >> >> Now I have done so and have started to think about the DOC: section, >> explaining what the library does. And I'm stuck, what's the benefit of >> using shmem compared to just using alloc_page()? > > Gives you swapping (and eventually maybe even migration) since there's > a real filesystem behind it. Atm this only works if you register a > shrinker callback, which for display drivers is a bit overkill. See > i915 or msm for examples (or ttm, if you want an entire fancy > framework), and git grep shrinker -- drivers/gpu. The shrinker is only needed if you need some impetus to unbind objects from your page tables, right? If you're just binding the pages for the moment that you're doing SPI transfers to the display, then in the remaining time it could be swapped out, right? [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: drm: Why shmem? 2017-08-29 17:40 ` Eric Anholt @ 2017-08-30 7:40 ` Daniel Vetter 2017-09-14 23:40 ` Noralf Trønnes 0 siblings, 1 reply; 9+ messages in thread From: Daniel Vetter @ 2017-08-30 7:40 UTC (permalink / raw) To: Eric Anholt; +Cc: dri-devel On Tue, Aug 29, 2017 at 10:40:04AM -0700, Eric Anholt wrote: > Daniel Vetter <daniel@ffwll.ch> writes: > > > On Mon, Aug 28, 2017 at 8:44 PM, Noralf Trønnes <noralf@tronnes.org> wrote: > >> Hi, > >> > >> Currently I'm using the cma library with tinydrm because it was so > >> simple to use even though I have to work around the fact that reads are > >> uncached. A bigger problem that I have become aware of, is that it > >> restricts the dma buffers it can import since they have to be continous. > >> > >> So I looked to udl and it uses shmem. Fine, let's make a shmem gem > >> library similar to the cma library. > >> > >> Now I have done so and have started to think about the DOC: section, > >> explaining what the library does. And I'm stuck, what's the benefit of > >> using shmem compared to just using alloc_page()? > > > > Gives you swapping (and eventually maybe even migration) since there's > > a real filesystem behind it. Atm this only works if you register a > > shrinker callback, which for display drivers is a bit overkill. See > > i915 or msm for examples (or ttm, if you want an entire fancy > > framework), and git grep shrinker -- drivers/gpu. > > The shrinker is only needed if you need some impetus to unbind objects > from your page tables, right? If you're just binding the pages for the > moment that you're doing SPI transfers to the display, then in the > remaining time it could be swapped out, right? Yup, and for SPI the setup overhead shouldn't matter. But everyone else probably wants to cache mappings and page lists, and that means some kind of shrinker to drop them when needed. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: drm: Why shmem? 2017-08-30 7:40 ` Daniel Vetter @ 2017-09-14 23:40 ` Noralf Trønnes 2017-09-15 0:45 ` Eric Anholt 0 siblings, 1 reply; 9+ messages in thread From: Noralf Trønnes @ 2017-09-14 23:40 UTC (permalink / raw) To: Daniel Vetter, Eric Anholt; +Cc: dri-devel Den 30.08.2017 09.40, skrev Daniel Vetter: > On Tue, Aug 29, 2017 at 10:40:04AM -0700, Eric Anholt wrote: >> Daniel Vetter <daniel@ffwll.ch> writes: >> >>> On Mon, Aug 28, 2017 at 8:44 PM, Noralf Trønnes <noralf@tronnes.org> wrote: >>>> Hi, >>>> >>>> Currently I'm using the cma library with tinydrm because it was so >>>> simple to use even though I have to work around the fact that reads are >>>> uncached. A bigger problem that I have become aware of, is that it >>>> restricts the dma buffers it can import since they have to be continous. >>>> >>>> So I looked to udl and it uses shmem. Fine, let's make a shmem gem >>>> library similar to the cma library. >>>> >>>> Now I have done so and have started to think about the DOC: section, >>>> explaining what the library does. And I'm stuck, what's the benefit of >>>> using shmem compared to just using alloc_page()? >>> Gives you swapping (and eventually maybe even migration) since there's >>> a real filesystem behind it. Atm this only works if you register a >>> shrinker callback, which for display drivers is a bit overkill. See >>> i915 or msm for examples (or ttm, if you want an entire fancy >>> framework), and git grep shrinker -- drivers/gpu. >> The shrinker is only needed if you need some impetus to unbind objects >> from your page tables, right? If you're just binding the pages for the >> moment that you're doing SPI transfers to the display, then in the >> remaining time it could be swapped out, right? > Yup, and for SPI the setup overhead shouldn't matter. But everyone else > probably wants to cache mappings and page lists, and that means some kind > of shrinker to drop them when needed. Let me see if I've understood this correctly: The first time I call drm_gem_get_pages() the buffer pages are allocated and pinned. When I then call drm_gem_put_pages() the pages are unpinned, but not freed. The kernel is now free to swap out the pages if necessary. Calling drm_gem_get_pages() a second time will swapin the pages if necessary and pin them. If this is correct, where are pages freed? Noralf. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: drm: Why shmem? 2017-09-14 23:40 ` Noralf Trønnes @ 2017-09-15 0:45 ` Eric Anholt 2017-09-15 14:38 ` Noralf Trønnes 0 siblings, 1 reply; 9+ messages in thread From: Eric Anholt @ 2017-09-15 0:45 UTC (permalink / raw) To: Noralf Trønnes, Daniel Vetter; +Cc: dri-devel [-- Attachment #1.1: Type: text/plain, Size: 2272 bytes --] Noralf Trønnes <noralf@tronnes.org> writes: > Den 30.08.2017 09.40, skrev Daniel Vetter: >> On Tue, Aug 29, 2017 at 10:40:04AM -0700, Eric Anholt wrote: >>> Daniel Vetter <daniel@ffwll.ch> writes: >>> >>>> On Mon, Aug 28, 2017 at 8:44 PM, Noralf Trønnes <noralf@tronnes.org> wrote: >>>>> Hi, >>>>> >>>>> Currently I'm using the cma library with tinydrm because it was so >>>>> simple to use even though I have to work around the fact that reads are >>>>> uncached. A bigger problem that I have become aware of, is that it >>>>> restricts the dma buffers it can import since they have to be continous. >>>>> >>>>> So I looked to udl and it uses shmem. Fine, let's make a shmem gem >>>>> library similar to the cma library. >>>>> >>>>> Now I have done so and have started to think about the DOC: section, >>>>> explaining what the library does. And I'm stuck, what's the benefit of >>>>> using shmem compared to just using alloc_page()? >>>> Gives you swapping (and eventually maybe even migration) since there's >>>> a real filesystem behind it. Atm this only works if you register a >>>> shrinker callback, which for display drivers is a bit overkill. See >>>> i915 or msm for examples (or ttm, if you want an entire fancy >>>> framework), and git grep shrinker -- drivers/gpu. >>> The shrinker is only needed if you need some impetus to unbind objects >>> from your page tables, right? If you're just binding the pages for the >>> moment that you're doing SPI transfers to the display, then in the >>> remaining time it could be swapped out, right? >> Yup, and for SPI the setup overhead shouldn't matter. But everyone else >> probably wants to cache mappings and page lists, and that means some kind >> of shrinker to drop them when needed. > > Let me see if I've understood this correctly: > > The first time I call drm_gem_get_pages() the buffer pages are > allocated and pinned. > When I then call drm_gem_put_pages() the pages are unpinned, but not freed. > The kernel is now free to swap out the pages if necessary. > Calling drm_gem_get_pages() a second time will swapin the pages if > necessary and pin them. > > If this is correct, where are pages freed? drm_gem_object_release() during freeing of the object. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: drm: Why shmem? 2017-09-15 0:45 ` Eric Anholt @ 2017-09-15 14:38 ` Noralf Trønnes 2017-09-16 22:10 ` Eric Anholt 0 siblings, 1 reply; 9+ messages in thread From: Noralf Trønnes @ 2017-09-15 14:38 UTC (permalink / raw) To: Eric Anholt, Daniel Vetter; +Cc: dri-devel Den 15.09.2017 02.45, skrev Eric Anholt: > Noralf Trønnes <noralf@tronnes.org> writes: > >> Den 30.08.2017 09.40, skrev Daniel Vetter: >>> On Tue, Aug 29, 2017 at 10:40:04AM -0700, Eric Anholt wrote: >>>> Daniel Vetter <daniel@ffwll.ch> writes: >>>> >>>>> On Mon, Aug 28, 2017 at 8:44 PM, Noralf Trønnes <noralf@tronnes.org> wrote: >>>>>> Hi, >>>>>> >>>>>> Currently I'm using the cma library with tinydrm because it was so >>>>>> simple to use even though I have to work around the fact that reads are >>>>>> uncached. A bigger problem that I have become aware of, is that it >>>>>> restricts the dma buffers it can import since they have to be continous. >>>>>> >>>>>> So I looked to udl and it uses shmem. Fine, let's make a shmem gem >>>>>> library similar to the cma library. >>>>>> >>>>>> Now I have done so and have started to think about the DOC: section, >>>>>> explaining what the library does. And I'm stuck, what's the benefit of >>>>>> using shmem compared to just using alloc_page()? >>>>> Gives you swapping (and eventually maybe even migration) since there's >>>>> a real filesystem behind it. Atm this only works if you register a >>>>> shrinker callback, which for display drivers is a bit overkill. See >>>>> i915 or msm for examples (or ttm, if you want an entire fancy >>>>> framework), and git grep shrinker -- drivers/gpu. >>>> The shrinker is only needed if you need some impetus to unbind objects >>>> from your page tables, right? If you're just binding the pages for the >>>> moment that you're doing SPI transfers to the display, then in the >>>> remaining time it could be swapped out, right? >>> Yup, and for SPI the setup overhead shouldn't matter. But everyone else >>> probably wants to cache mappings and page lists, and that means some kind >>> of shrinker to drop them when needed. >> Let me see if I've understood this correctly: >> >> The first time I call drm_gem_get_pages() the buffer pages are >> allocated and pinned. >> When I then call drm_gem_put_pages() the pages are unpinned, but not freed. >> The kernel is now free to swap out the pages if necessary. >> Calling drm_gem_get_pages() a second time will swapin the pages if >> necessary and pin them. >> >> If this is correct, where are pages freed? > drm_gem_object_release() during freeing of the object. > I see that you get the pages in vc5_bo_create() and put them in vc5_free_object(). This means that you don't benefit from the shmem "advantage" of swapping. Why do you use shmem? Simplicity since it's built into DRM? For me shmem has one drawback and that is fbdev deferred IO. It doesn't work with shmem pages, since they compete over page->lru. That requires me to use a shadow buffer for fbdev as a work around. I can't use the shmem buffer directly. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: drm: Why shmem? 2017-09-15 14:38 ` Noralf Trønnes @ 2017-09-16 22:10 ` Eric Anholt 0 siblings, 0 replies; 9+ messages in thread From: Eric Anholt @ 2017-09-16 22:10 UTC (permalink / raw) To: Noralf Trønnes, Daniel Vetter; +Cc: dri-devel [-- Attachment #1.1: Type: text/plain, Size: 2777 bytes --] Noralf Trønnes <noralf@tronnes.org> writes: > Den 15.09.2017 02.45, skrev Eric Anholt: >> Noralf Trønnes <noralf@tronnes.org> writes: >> >>> Den 30.08.2017 09.40, skrev Daniel Vetter: >>>> On Tue, Aug 29, 2017 at 10:40:04AM -0700, Eric Anholt wrote: >>>>> Daniel Vetter <daniel@ffwll.ch> writes: >>>>> >>>>>> On Mon, Aug 28, 2017 at 8:44 PM, Noralf Trønnes <noralf@tronnes.org> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Currently I'm using the cma library with tinydrm because it was so >>>>>>> simple to use even though I have to work around the fact that reads are >>>>>>> uncached. A bigger problem that I have become aware of, is that it >>>>>>> restricts the dma buffers it can import since they have to be continous. >>>>>>> >>>>>>> So I looked to udl and it uses shmem. Fine, let's make a shmem gem >>>>>>> library similar to the cma library. >>>>>>> >>>>>>> Now I have done so and have started to think about the DOC: section, >>>>>>> explaining what the library does. And I'm stuck, what's the benefit of >>>>>>> using shmem compared to just using alloc_page()? >>>>>> Gives you swapping (and eventually maybe even migration) since there's >>>>>> a real filesystem behind it. Atm this only works if you register a >>>>>> shrinker callback, which for display drivers is a bit overkill. See >>>>>> i915 or msm for examples (or ttm, if you want an entire fancy >>>>>> framework), and git grep shrinker -- drivers/gpu. >>>>> The shrinker is only needed if you need some impetus to unbind objects >>>>> from your page tables, right? If you're just binding the pages for the >>>>> moment that you're doing SPI transfers to the display, then in the >>>>> remaining time it could be swapped out, right? >>>> Yup, and for SPI the setup overhead shouldn't matter. But everyone else >>>> probably wants to cache mappings and page lists, and that means some kind >>>> of shrinker to drop them when needed. >>> Let me see if I've understood this correctly: >>> >>> The first time I call drm_gem_get_pages() the buffer pages are >>> allocated and pinned. >>> When I then call drm_gem_put_pages() the pages are unpinned, but not freed. >>> The kernel is now free to swap out the pages if necessary. >>> Calling drm_gem_get_pages() a second time will swapin the pages if >>> necessary and pin them. >>> >>> If this is correct, where are pages freed? >> drm_gem_object_release() during freeing of the object. >> > > I see that you get the pages in vc5_bo_create() and put them in > vc5_free_object(). This means that you don't benefit from the shmem > "advantage" of swapping. > Why do you use shmem? Simplicity since it's built into DRM? I *just* started writing this driver. I'm not unpinning objects under memory pressure ye.t [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-09-16 22:10 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-08-28 18:44 drm: Why shmem? Noralf Trønnes 2017-08-28 20:40 ` Eric Anholt 2017-08-28 20:45 ` Daniel Vetter 2017-08-29 17:40 ` Eric Anholt 2017-08-30 7:40 ` Daniel Vetter 2017-09-14 23:40 ` Noralf Trønnes 2017-09-15 0:45 ` Eric Anholt 2017-09-15 14:38 ` Noralf Trønnes 2017-09-16 22:10 ` Eric Anholt
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.