From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9415D89AC9 for ; Thu, 14 Oct 2021 05:18:50 +0000 (UTC) Date: Wed, 13 Oct 2021 22:01:22 -0700 Message-ID: <871r4oi4il.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" In-Reply-To: <20211008065432.15482-8-zbigniew.kempczynski@intel.com> References: <20211008065432.15482-1-zbigniew.kempczynski@intel.com> <20211008065432.15482-8-zbigniew.kempczynski@intel.com> MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Subject: Re: [igt-dev] [PATCH i-g-t 7/7] benchmarks/gem_exec_fault: Add softpin mode to support gens with ppgtt List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" To: Zbigniew =?ISO-8859-2?Q?Kempczy=F1ski?= Cc: igt-dev@lists.freedesktop.org, Petri Latvala List-ID: On Thu, 07 Oct 2021 23:54:32 -0700, Zbigniew Kempczy=F1ski wrote: > > + /* > + * For older gens .alignment =3D 1ull << 63 lead do bind/unbind, > + * what doesn't work for newer gens with ppgtt. > + * For ppgtt case we use reloc allocator which would just assigns > + * new offset for each batch. This way we enforce bind/unbind vma > + * for each execbuf. So assigning a new offset will cause a new fault-in (bind) but not sure if it will cause an actual fault-out (unbind). Though I am not sure if there is actually a way to force it to happen if this doesn't work? Is there a way to verify that the unbind is actually happening? Neither I am sure how setting the 'alignment =3D 1ull << 63' caused a fault out in the older code. > + */ > + has_ppgtt =3D gem_uses_full_ppgtt(fd); > + if (has_ppgtt) { > + igt_info("Using softpin mode\n"); > + intel_allocator_multiprocess_start(); > + } else { > + igt_assert(gem_allows_passing_alignment(fd)); I think this should be igt_require for the test to skip rather than fail. > +/* > + * NOTE: Ensure prove locking in the kernel is off, otherwise results > + * would be inaccurate. > + */ This is really a debug setting, any such setting (say lockdep, kmemchek etc.) will affect benchmarks. So not sure if this specifically needs to be called out.