From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zhenyu Wang Subject: Re: [PATCH 02/10] drm/i915/gvt: Pin the per-engine GVT shadow contexts Date: Fri, 26 Apr 2019 11:30:54 +0800 Message-ID: <20190426033054.GE17995@zhen-hp.sh.intel.com> References: <20190425054210.27065-1-chris@chris-wilson.co.uk> <20190425054210.27065-2-chris@chris-wilson.co.uk> <155620942405.3869.12593455008445823620@skylake-alporthouse-com> Reply-To: Zhenyu Wang Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1073534425==" Return-path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7C884892DE for ; Fri, 26 Apr 2019 03:31:02 +0000 (UTC) In-Reply-To: <155620942405.3869.12593455008445823620@skylake-alporthouse-com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Chris Wilson Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============1073534425== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wPZoOnycM2UpxKV4" Content-Disposition: inline --wPZoOnycM2UpxKV4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019.04.25 17:23:44 +0100, Chris Wilson wrote: > Quoting Chris Wilson (2019-04-25 06:42:02) > > Our eventual goal is to rid request construction of struct_mutex, with > > the short term step of lifting the struct_mutex requirements into the > > higher levels (i.e. the caller must ensure that the context is already > > pinned into the GTT). In this patch, we pin GVT's shadow context upon > > allocation and so keep them pinned into the GGTT for as long as the > > virtual machine is alive, and so we can use the simpler request > > construction path safe in the knowledge that the hard work is already > > done. > >=20 > > Signed-off-by: Chris Wilson > > Cc: Zhenyu Wang >=20 > Hi Zhenyu, could you check through this patch and make sure I haven't > broken gvt in the process? > > The end result is that the gvt shadow context is always pinned into the > ggtt, avoids any eviction/shrinking, and so allows gvt to use the faster > paths for request allocation. yeah, the change looks sane to me. I still like to run some regression test on this before merging, will reply result to you. --=20 Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 --wPZoOnycM2UpxKV4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTXuabgHDW6LPt9CICxBBozTXgYJwUCXMJ7bgAKCRCxBBozTXgY JwCHAJ9pNdXZIqyWz0axGNDPOiVzL5g/zQCZAfos7fhQ+54vaetC+HGg2I//XQ4= =B25r -----END PGP SIGNATURE----- --wPZoOnycM2UpxKV4-- --===============1073534425== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4 --===============1073534425==--