From mboxrd@z Thu Jan 1 00:00:00 1970 From: Francisco Jerez Subject: Re: [Intel-gfx] [PATCH] drm/i915: Set all undefined MOCS entries to follow PTE Date: Thu, 04 May 2017 13:59:44 -0700 Message-ID: <87k25wbanz.fsf@riseup.net> References: <20170504150245.wuahcnen5ebbg4js@boom> <87wp9wbj4p.fsf@riseup.net> <20170504200333.GK24019@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: In-Reply-To: <20170504200333.GK24019@nuc-i3427.alporthouse.com> Sender: stable-owner@vger.kernel.org To: Chris Wilson Cc: David Weinehall , intel-gfx@lists.freedesktop.org, stable@vger.kernel.org List-Id: intel-gfx@lists.freedesktop.org --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Chris Wilson writes: > On Thu, May 04, 2017 at 10:56:54AM -0700, Francisco Jerez wrote: >> David Weinehall writes: >>=20 >> > On Thu, May 04, 2017 at 10:51:29AM +0100, Chris Wilson wrote: >> >> A good default for garbage entries from the user is to follow the >> >> default setting of the object (i.e. the PTE). Currently they use the >> >> uncached entry, and now the only way to accidentally hit uncached >> >> performance is via explicit use of the uncached MOCS or setting the >> >> object to uncached. Note that these entries are currently undefined in >> >> the ABI and we reserve the right to change them. We originally chose >> >> uncached to eliminate any problem with reducing the caching level in >> >> future, but the object is a much better definition of the minimum >> >> caching level. >> >>=20 >>=20 >> NAK. The reason for the default being UC is that it's the only setting >> that guarantees full forwards compatibility with any other entry that >> might be added in the future. If you default to PTE on (e)LLC and WB on >> L3, userspace will no longer be able to use any newly introduced entry >> with stricter coherency guarantees than that (e.g. any L3-uncached >> entry) in a backwards-compatible way. Attempting to do so may break >> memory coherency assumptions of the application and lead to misrendering >> when run on older kernel versions (which to my judgment is a scarier >> failure mode than reduced performance). > > You can't use a weaker coherency model in mocs than that specified for > the object as you can't control other uses of the object (even just > memory pressure will break your assumptions). Exactly, but you can use a stronger coherency model than the application requested, which is why falling back to UC should generally work for unknown entries but falling back to PTE+WB isn't guaranteed to. > -Chris > > --=20 > Chris Wilson, Intel Open Source Technology Centre --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlkLlkAACgkQg5k4nX1Sv1u9igD9GW0RR6Nup+S3fnL6Q/00Ee9F RzgaXleEC1i5Nh0ZN0MA/RTOrleeQqFyNKC4rCK3xutNSGaLbr3BT3GqbLwa/BQ5 =UAfz -----END PGP SIGNATURE----- --==-=-=--