From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by gabe.freedesktop.org (Postfix) with ESMTPS id 747476E95D for ; Fri, 6 Aug 2021 01:32:53 +0000 (UTC) Date: Thu, 05 Aug 2021 18:15:34 -0700 Message-ID: <875ywjtlu1.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" In-Reply-To: <87fsvnu3i5.wl-ashutosh.dixit@intel.com> References: <20210726200026.4815-1-zbigniew.kempczynski@intel.com> <20210726200026.4815-3-zbigniew.kempczynski@intel.com> <87k0l2kztn.wl-ashutosh.dixit@intel.com> <87eebakqp3.wl-ashutosh.dixit@intel.com> <20210804061341.GA4891@zkempczy-mobl2> <87fsvnu3i5.wl-ashutosh.dixit@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 v3 02/52] lib/intel_allocator: Add few helper functions for common use 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 List-ID: On Thu, 05 Aug 2021 11:53:54 -0700, Dixit, Ashutosh wrote: > > On Tue, 03 Aug 2021 23:13:41 -0700, Zbigniew Kempczy=F1ski wrote: > > > > Even if Simple is stateful we got some case in which its usage > > is currently limited (so you can see using reloc in most of the > > tests). Problem is with... it is stateful. Most of tests creates batch > > (gem object), use it and destroy it. From allocator perspective we alloc > > offset, then we free it. In next round we got same offset for another b= atch > > (gem object). So kernel serialize the execution until previous vma is f= reed. > > This lead to non-pipelined execution. > > Maybe I am wrong but to me it looks fixable. Maybe we need to keep track = of > the "last allocated offset" in simple so that next time we allocate a new > offset even if the previous one has been freed (rather than reallocating > the previous offset). Or we can allocate starting from a random offset? > > > You can see pattern in many tests - ahnd =3D get_reloc_ahnd(...), > > get offset for scratch surface, then pass scratch_offset to some execut= ion > > function. This allows to keep us same offset for scratch and get new > > offsets for batches. So I think I see this in e.g. the gem_exec_async patch. Allocating new offsets for batches helps to avoid the stalls mentioned above, correct? > > The best would be to have something hybrid which would propose new (and > > not busy) bb, but that should happen in multiprocess env so I haven't > > found how to write this yet. Libdrm handles pools of objects and reuses > > them if they were not busy. But doing this in multiprocess requires > > synchronization so some additional mechanism should be added to > > allocator to handle this case. What I proposed above using "last allocated offset" will not work in the multiprocess env? > > I still wonder to introduce .dependency_offset in creating spinner when > > .dependency handle is passed. Currently we have to use Simple to ensure > > we got same offset for .dependency. As spinners keep batch handles until > > they are freed this likely is not a problem. But it may be in the > > future. OK. > I am not following the above two paragraphs, maybe we can discuss more so= me > time. I do follow what you are saying now somewhat. Thank you.