public inbox for intel-gfx@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox