From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: drm: Why shmem? Date: Sat, 16 Sep 2017 15:10:33 -0700 Message-ID: <87r2v6s3ae.fsf@anholt.net> References: <87ziaiqnm3.fsf@anholt.net> <20170830074058.x7rlh6oxxgigaj6c@phenom.ffwll.local> <5ba14eb7-70c3-69ae-ba9b-ea9ba27d4b7e@tronnes.org> <87bmmcvlfg.fsf@anholt.net> <0d4ee426-4482-5354-48f2-bb9f42d6bf74@tronnes.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1772907644==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id 59CC06E201 for ; Sat, 16 Sep 2017 22:10:38 +0000 (UTC) In-Reply-To: <0d4ee426-4482-5354-48f2-bb9f42d6bf74@tronnes.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Noralf =?utf-8?Q?Tr=C3=B8nnes?= , Daniel Vetter Cc: dri-devel List-Id: dri-devel@lists.freedesktop.org --===============1772907644== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Noralf Tr=C3=B8nnes writes: > Den 15.09.2017 02.45, skrev Eric Anholt: >> Noralf Tr=C3=B8nnes 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 writes: >>>>> >>>>>> On Mon, Aug 28, 2017 at 8:44 PM, Noralf Tr=C3=B8nnes 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 conti= nous. >>>>>>> >>>>>>> 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 t= he >>>>> 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 k= ind >>>> 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 fr= eed. >>> 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlm9oVkACgkQtdYpNtH8 nugCFQ/+Iso70jKJYB4mFSdr0MSQ3fMbKflCyk2mkLMhmGvL36ZjZPllvMncE8bD DmTGiTvACPIQII7TAKLL3axZ9sFyjiW/gN3DahwbLQFRKSp+3La0E1nYz1v1AFDJ COATDlQe+WuMrkYezz31AKHe3oszLhAjxNuDn+GX7BdtIJ/WAnPp/3ePy/g+U85W xwkSjb5m/bEeuf2gUfCsV/Dwra+fAbCtZVdbil4ztjswz1PboYRflS1jLFSyNvKJ 5Eqcr1EMj49RkjMkxupp81bDoO9d+705Yw7XmKWn8r8L7uknucHdKKPegygvYdpu 4za/NDVBcMxzfbxb4ue2C/kt3id8Xr32OXB3DTjr/vY5+lGQuK4P3hqRSsV16Nyv iQ1xMowE4/mDWywRgZhMyg2xs1eTsQMZIgBDIIq3Do8v8eWxQzxcsFJGrCkpU3sx EohdvjZVzagOEjOghP0eX91hJjaJgG1JmocS5trCKedUIuKpN94AoQ9rpQoBnDjZ CcIROw/MY5S/Jsc6RFPgzsUdMkEeZXPRvsU0tRGKI+igDwnLqNBYmaFyArWIOcqg ELCISmL/cTd+Z3bLjBx6I+iysWAnEPdg7EvTFw6wNl99uBPmTGiBVLGNqsQv/47m IJtzbD0f/8LnPiK2pKiPFlv0FQbBAaxFq4E8ZDq0CvZnYvscIx0= =jozH -----END PGP SIGNATURE----- --=-=-=-- --===============1772907644== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1772907644==--