From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 0/9] [RFC] fair-lru eviction Date: Wed, 19 May 2010 22:13:42 +0200 Message-ID: <20100519201341.GD3537@viiv.ffwll.ch> References: <1274217111-3882-1-git-send-email-daniel.vetter@ffwll.ch> <4BF44145.1020006@shipmail.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <4BF44145.1020006@shipmail.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Thomas =?iso-8859-1?Q?Hellstr=F6m?= Cc: Daniel Vetter , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Wed, May 19, 2010 at 09:51:33PM +0200, Thomas Hellstr=F6m wrote: > Daniel, > TTM releases the spinlock protecting the drm_mm manager in between > evictions to be able to wait (without holding locks) for bo idle. > That means that the lru list may have changed between the first > eviction and the next. In practice, drivers either don't allow > simultaneous bo validation or should disallow it if thrashing is > likely to occur, so the likelyhood of the lru list changing in > between evictions should be small but it needs to be taken into > account. Well, in my opinion ttm locking optimize for the wrong case: Usually there should be a little bit of room free to fully pipeline everything. And if it there is no room free anymore, performance is gonna dip anyway, so we might as well block. I think the linux vm with the split between asynchronous background writeback and synchronous writeback in case of low amounts of free memory could be used as inspiration. Whatever, I think ttm could use this fair eviction stuff even with the current locking scheme: Do all the accounting under the spinlock, i.e. - scanning the lru - building up the eviction list - mark the memory blocks as free (with drm_mm_put_block) - reserve the complete free hole (needs a new function in drm_mm, but range-restricted allocations are not yet implemented yet, anyway) with a temporary object. Then do the effective eviction outside the spinlock. iirc ttm already uses such shadow (dunno what they're really called) objects for buffer moves. > Nevertheless, the drm_mm.c cleanup is > Acked-by: Thomas Hellstrom Does that include the drm_mm_node->private pointer removal? Jerome naked that one (but I've objected). Just to clarify. > I'll leave it to the Intel guys to comment on the fair eviction stuff. > = > /Thomas Thanks, Daniel -- = Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48