From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: drm: Why shmem? Date: Thu, 14 Sep 2017 17:45:55 -0700 Message-ID: <87bmmcvlfg.fsf@anholt.net> References: <87ziaiqnm3.fsf@anholt.net> <20170830074058.x7rlh6oxxgigaj6c@phenom.ffwll.local> <5ba14eb7-70c3-69ae-ba9b-ea9ba27d4b7e@tronnes.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0679719555==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id 5ACC56EB2B for ; Fri, 15 Sep 2017 00:45:58 +0000 (UTC) In-Reply-To: <5ba14eb7-70c3-69ae-ba9b-ea9ba27d4b7e@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 --===============0679719555== 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 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 a= re >>>>> 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 contino= us. >>>>> >>>>> 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 free= d. > 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. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlm7IsMACgkQtdYpNtH8 nuhnzg//bqKEtYRtUe0VOubP5Q5Fs4FgmdJDwwGtG7G/04qnHR6hcp/0x1NGr835 mspae7jEKXmuD0Np2Cwlpumnio+6zkUP1SkoTIEWZHuf6CyxOQ2NJJHRE03P2Mj+ oHifsLdnLkNQlt6ktCprFzZqMPmpbbp/yDilVlvUO/+XT+hyQOoi4a3e58Uw7yS/ QCASbOYVY4BIXxhFUz3ioEmB4r2ZXbGSYNiVEu6Uhfjomq7CjqVyYU76oaIT4DBX h/rZy/JozYwAMYhlU2sIh3fJ/I8TAn+fYIvLHTIhbLeyFU9C8Rj52G9mBt8+vCWk YaGXBNrdPTJWQ8DJo0xIuSM6WsNL+LDS0AgYcq82OcE2mrBGbf44HjKsw3jIS86v p9SpX+OFtS08m3lKsEh5totoPduwXJpnfghicGy2fnFcsjNBkls58/xntsQjEoAP z7UoF0cJVit4h+ZF8O48hFDLm9wgNuj5thGt01P/4sE4pYTdQXGpc6147297Bjai ZLDncIZGxaIxQSBoRPL2Lu/Mg8WKXdcDhlfdqr5ro32iryNsTgfyvM9yzBilKaAc y+eUpVARUUWpD+WL+Yr8ChLX8aTjdc3q4Z0W/ctCVAkAUIkFWwsvSYQA3A7H677L Vzqt79OzcUXfzVsomFUWyyKxyy/YbzFDzO0VKECf0I+Wb6oTEj4= =a3Bf -----END PGP SIGNATURE----- --=-=-=-- --===============0679719555== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0679719555==--