All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Widawsky <ben@bwidawsk.net>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Ben Widawsky <benjamin.widawsky@intel.com>,
	Intel GFX <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/9] drm/i915: Extract node allocation from bind
Date: Wed, 7 May 2014 09:00:16 -0700	[thread overview]
Message-ID: <20140507160015.GD5147@bwidawsk.net> (raw)
In-Reply-To: <20140507155308.GH7322@nuc-i3427.alporthouse.com>

On Wed, May 07, 2014 at 04:53:08PM +0100, Chris Wilson wrote:
> On Wed, May 07, 2014 at 08:45:38AM -0700, Ben Widawsky wrote:
> > On Wed, May 07, 2014 at 08:02:38AM +0100, Chris Wilson wrote:
> > > On Tue, May 06, 2014 at 10:21:31PM -0700, Ben Widawsky wrote:
> > > > The DRM node allocation code was already a bit of an ugly bit of code
> > > > within a complex function. Removing it serves the purpose of cleaning
> > > > the function up. More importantly, it provides a way to have a
> > > > preallocated (address space) VMA to easily skip this code. Something
> > > > we're very likely to need.
> > > > 
> > > > This is essentially a wrapper for DRM node allocation with an eviction +
> > > > retry. It is something which could be moved to core DRM eventually, if
> > > > other drivers had similar eviction semantics.
> > > > 
> > > > This removes a goto used for something other than error unwinding, a
> > > > generally reviled (I am neutral) practice, and replaces it with a
> > > > function call to itself that should have the same effect. Note that it's
> > > > not a recursive function as all the problem set reduction is done in the
> > > > eviction code.
> > > > 
> > > > Some might say this change is worse than before because we are using
> > > > stack for each subsequent call. Frankly, I'd rather overflow the stack
> > > > and blow it up than loop forever. In either case, this is addressed in
> > > > the next patch.
> > > > 
> > > > I believe, and intend, that other than the stack usage, there is no
> > > > functional change here.
> > > 
> > > Nope, but decoupling evict_something() further does introduce lots more
> > > implied magic.
> > > -Chris
> > > 
> > 
> > Hmm. I really don't see what's actually upsetting. Can you be a bit more
> > explicit about what's so bothersome to you for my edification?
> 
> evict_something() make assumptions about the ranges of the vm which it
> searches. At the moment, they mirror its parent's function.
> -Chris
> 

Ah, thanks. So is plumbing starting eviction offset into evict something an
appealing solution here?

> -- 
> Chris Wilson, Intel Open Source Technology Centre

-- 
Ben Widawsky, Intel Open Source Technology Center

  reply	other threads:[~2014-05-07 16:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-07  5:21 [PATCH 1/9] drm/i915: Use topdown allocation for PPGTT PDEs on gen6/7 Ben Widawsky
2014-05-07  5:21 ` [PATCH 2/9] drm/i915: Extract node allocation from bind Ben Widawsky
2014-05-07  7:02   ` Chris Wilson
2014-05-07 15:45     ` Ben Widawsky
2014-05-07 15:53       ` Chris Wilson
2014-05-07 16:00         ` Ben Widawsky [this message]
2014-05-07 16:55           ` Chris Wilson
2014-05-07 17:30             ` Ben Widawsky
2014-05-07  5:21 ` [PATCH 3/9] drm/i915: WARN on unexpected return from drm_mm Ben Widawsky
2014-05-07  5:21 ` [PATCH 4/9] drm/i915: Limit the number of node allocation retries Ben Widawsky
2014-05-07  7:49   ` Daniel Vetter
2014-05-07 15:21     ` Ben Widawsky
2014-05-07  5:21 ` [PATCH 5/9] drm/i915: Use new drm node allocator for PPGTT Ben Widawsky
2014-05-07  5:21 ` [PATCH 6/9] drm/i915: Wrap VMA binding Ben Widawsky
2014-05-07  7:55   ` Daniel Vetter
2014-05-07 15:54     ` Ben Widawsky
2014-05-07 16:09       ` Daniel Vetter
2014-05-07  5:21 ` [PATCH 7/9] drm/i915: Make aliasing a 2nd class VM Ben Widawsky
2014-05-07  7:56   ` Daniel Vetter
2014-05-07  5:21 ` [PATCH 8/9] drm/i915: Make pin global flags explicit Ben Widawsky
2014-05-07  5:21 ` [PATCH 9/9] drm/i915: Split out aliasing binds Ben Widawsky
2014-05-07  7:59   ` Daniel Vetter
2014-05-07  7:44 ` [PATCH 1/9] drm/i915: Use topdown allocation for PPGTT PDEs on gen6/7 Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140507160015.GD5147@bwidawsk.net \
    --to=ben@bwidawsk.net \
    --cc=benjamin.widawsky@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.