From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH] drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl Date: Wed, 27 Sep 2017 11:49:21 -0700 Message-ID: <8760c4dlji.fsf@anholt.net> References: <20170927141054.32728-1-boris.brezillon@free-electrons.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0202777566==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id 461E86E7DA for ; Wed, 27 Sep 2017 18:49:25 +0000 (UTC) In-Reply-To: <20170927141054.32728-1-boris.brezillon@free-electrons.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Cc: Boris Brezillon , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0202777566== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Boris Brezillon writes: > This ioctl will allow us to purge inactive userspace buffers when the > system is running out of contiguous memory. > > For now, the purge logic is rather dumb in that it does not try to > release only the amount of BO needed to meet the last CMA alloc request > but instead purges all objects placed in the purgeable pool as soon as > we experience a CMA allocation failure. > > Note that the in-kernel BO cache is always purged before the purgeable > cache because those objects are known to be unused while objects marked > as purgeable by a userspace application/library might have to be > restored when they are marked back as unpurgeable, which can be > expensive. > > Signed-off-by: Boris Brezillon > --- > Hello, > > Updates to libdrm, mesa and igt making use of this kernel feature can > be found on my github repos [1][2][3]. > > There's currently no debugfs hook to manually force a purge, but this > is being discussed and will probably be added in v2. > > Regards, > diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h > index afae87004963..c01b93d453db 100644 > --- a/include/uapi/drm/vc4_drm.h > +++ b/include/uapi/drm/vc4_drm.h > @@ -41,6 +41,7 @@ extern "C" { > #define DRM_VC4_SET_TILING 0x08 > #define DRM_VC4_GET_TILING 0x09 > #define DRM_VC4_LABEL_BO 0x0a > +#define DRM_VC4_GEM_MADVISE 0x0b >=20=20 > #define DRM_IOCTL_VC4_SUBMIT_CL DRM_IOWR(DRM_COMMAND_BASE + DR= M_VC4_SUBMIT_CL, struct drm_vc4_submit_cl) > #define DRM_IOCTL_VC4_WAIT_SEQNO DRM_IOWR(DRM_COMMAND_BASE + DR= M_VC4_WAIT_SEQNO, struct drm_vc4_wait_seqno) > @@ -53,6 +54,7 @@ extern "C" { > #define DRM_IOCTL_VC4_SET_TILING DRM_IOWR(DRM_COMMAND_BASE + DR= M_VC4_SET_TILING, struct drm_vc4_set_tiling) > #define DRM_IOCTL_VC4_GET_TILING DRM_IOWR(DRM_COMMAND_BASE + DR= M_VC4_GET_TILING, struct drm_vc4_get_tiling) > #define DRM_IOCTL_VC4_LABEL_BO DRM_IOWR(DRM_COMMAND_BASE + DR= M_VC4_LABEL_BO, struct drm_vc4_label_bo) > +#define DRM_IOCTL_VC4_GEM_MADVISE DRM_IOWR(DRM_COMMAND_BASE + DR= M_VC4_GEM_MADVISE, struct drm_vc4_gem_madvise) >=20=20 > struct drm_vc4_submit_rcl_surface { > __u32 hindex; /* Handle index, or ~0 if not present. */ > @@ -333,6 +335,16 @@ struct drm_vc4_label_bo { > __u64 name; > }; >=20=20 > +#define VC4_MADV_WILLNEED 0 > +#define VC4_MADV_DONTNEED 1 > +#define __VC4_MADV_PURGED 2 > + > +struct drm_vc4_gem_madvise { > + __u32 handle; > + __u32 madv; > + __u32 retained; > +}; danvet had a note in http://blog.ffwll.ch/2013/11/botching-up-ioctls.html: Pad the entire struct to a multiple of 64bits - the structure size will otherwise differ on 32bit versus 64bit. Which hurts when passing arrays of structures to the kernel. Or with the ioctl structure size checking that e.g. the drm core does. I'm surprised that i915's ioctl didn't do this or have compat code to handle it. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlnL8rEACgkQtdYpNtH8 nugSmRAApNiy+JqrNX77mTQnm5gxx1cwTAADGtfKzD7O5nWmHMI289O/mbVvK5Tf 1b0Rlpo6Mi5lJ3ZrpPKwQgzfQXUqb4IbLizjZSnAzS2YEPzI+C7yK9GSHdjgWdP9 D3W85V3PvNkJUra8wTlqVaI4/euiIHCHhXi6XOcyHzb8sGGaZUwXFQWgX0EALiKv yCum+41f1TGU+GBoNoxIpg3+5D4s6ciA6u3chReCpshloZgq0xyjz8vdYRdrcZLs 2ovI9UTx5NKiUw0VWuaJm2jX8yR5p2P0yhmnBvCZHoxrl3N3urXh/nAMX59lXtip 2pFzKG/3yWUk/vodv8kc0peWkJCQNciF/v5MoQoNi6NLC+plErrycjdldEE4n7Of eUvtHnZBDmYEeZcVgihPMReHfPvreOaWaDbjbeEmGXOkDRAds2SoYwq2k4jioGhq TlsU/j1faQpgeHetrmiWADZzFBAz1FMviThnq/mh3rujlYlUW7htyKtXAAdN8lEg l3xpeLLT9efubenFX6Ls+B/A5fOJAvYF+hKcEtTRQIaZ819c8+++jBAFpP2IPQkz CndzfFdm6bSdDlosbrWi4uNpK9Ahbrmh0cSIu1DzAky+6EO1w9+zYJy+uXdYto1v +zkyF35IMJl+DccBsG+NP8q6KCEW6+iKYAgmiKA19plnWFVojzc= =JXf8 -----END PGP SIGNATURE----- --=-=-=-- --===============0202777566== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0202777566==--