From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Thomas_Hellstr=F6m?= Subject: Re: [PATCH 0/7] drm/ttm: Pool allocator Date: Fri, 19 Mar 2010 20:51:47 +0100 Message-ID: <4BA3D5D3.30701@shipmail.org> References: <1268859006-18707-1-git-send-email-suokkos@gmail.com> <4BA36207.1070501@shipmail.org> <548cdfc21003190541g7664b786ud44073cbdc0747b9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <548cdfc21003190541g7664b786ud44073cbdc0747b9@mail.gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.sourceforge.net To: Pauli Nieminen Cc: Dave Airlie , Jerome Glisse , DRI List-Id: dri-devel@lists.freedesktop.org Pauli Nieminen wrote: > 2010/3/19 Thomas Hellstr=F6m : > = >> Pauli, Dave and Jerome, >> >> Before reviewing this, Could you describe a bit how this interfaces with= the >> TTM memory accounting. It's important for some systems to be able to set= a >> limit beyond which TTM may not pin any pages. >> >> Am I right in assuming that TTM memory accounting is kicked in only when= TTM >> allocs and frees pages from the pool? >> = > > yes. > > TTM memory accounting is still handled in ttm_tt.c so pool is outside > of it. But I can move calls to memory accounting into pool if that is > preferred place. > > With current implementation pool can hold about 512 pages more memory > than what is the TTM limit. > > = In that case I think we should keep the pool outside of TTM memory = accounting. Since the system can (or should be able to) reclaim the pool pages = through the shrink mechanism, the pool is sort of transparent from a memory accounting point of view = although shrinking comes with a performance penalty. >> Can the system reclaim *all* pages not used by TTM through a shrink >> mechanism? >> = > > Not with current version but I can modify patch so that system can > reclaim all pages. Current lowest limit is 16 pages in pool because > that avoids refills for 2D only desktop use. > > The limit is already changed in runtime so making it scale to zero > sized pool is only minor change. But what should happen for pool > refill if system just before forced the pool size to zero? > = 16 pages sounds OK to me. Perhaps we'd want to be able to change both this limit and the upper = pool size limit from a sysfs interface, within ttm/memory_accounting ? > = >> In the long run, I'd like to have a pool of non-kernel-mapped pages inst= ead >> of a pool of uncached / write-combined pages, because then we'd have qui= te >> fast transition from write-combined to write-back, but I guess that will= be >> something for the future. >> = > > I think this can be simulated with multiple pools if free logic is > changed from handling single pool at a time to combine multiple pools > to a single wb transition operation. > Trouble in making very large cache transition operations is that > allocating large continues arrays in kernel is problematic. Current > code is limiting the size of single cache transition operation to > avoid possible memory allocation problems. > > = I think that's a good strategy. However, the use-case I was thinking of was not fast freeing, but fast = reading of GPU memory, like so: *) Unbind from AGP. *) Mark pages write-back() while the kernel map is still 'unmapped' = (just like highmem pages). *) Read *) Cache flush pages and Mark pages write-combined(), while the kernel = map is still 'unmapped'. The operation will not involve any 'set_pages_x' , because the kernel = map is not affected. However, there is no exported api to unmap pages from the linear kernel = map (yet). /Thomas >> /Thomas >> >> >> >> >> Pauli Nieminen wrote: >> = >>> When allocating wc/uc pages cache state transition requires cache flush >>> which >>> is expensive operation. To avoid cache flushes allocation of wc/uc pages >>> should >>> be done in large groups when only single cache flush is required for wh= ole >>> group >>> of pages. >>> >>> In some cases drivers need t oallocate and deallocate many pages in a >>> short time >>> frame. In this case we can avoid cache flushes if we keep pages in the >>> pool before >>> actually freeing them later. >>> >>> arch/x86 was missing set_pages_array_wc and set_memory_array_wc. Patch 6 >>> and 7 add >>> missing functions and hooks set_pages_array_wc to the pool allocator. >>> >>> >>> >>> -----------------------------------------------------------------------= ------- >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> -- >>> _______________________________________________ >>> Dri-devel mailing list >>> Dri-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/dri-devel >>> >>> = >> >> >> = ---------------------------------------------------------------------------= --- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev --