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>,
	Intel GFX <intel-gfx@lists.freedesktop.org>,
	Paul Berry <stereotype441@gmail.com>
Subject: Re: [PATCH 0/6] Page faults to help user space debug
Date: Fri, 28 Jun 2013 16:30:44 -0700	[thread overview]
Message-ID: <20130628233043.GA2141@bwidawsk.net> (raw)
In-Reply-To: <20130628223953.GA5210@cantiga.alporthouse.com>

On Fri, Jun 28, 2013 at 11:39:53PM +0100, Chris Wilson wrote:
> On Fri, Jun 28, 2013 at 03:23:31PM -0700, Ben Widawsky wrote:
> > This series originated from the request from Paul, "can you enable page
> > faults"?  After some though and discussion, we came up with 3 debug features to
> > implement:
> 
> The issue lies in that the CS and EU units like to prefetch 128 bytes
> and will cross page boundaries. Userspace is rather lax in providing the
> extra page (or preventing the read past the end of its bo) and so
> without adding a sentinel page behind every bo you quickly generate
> false positives. (Unless you also run a fixed userspace).
> 
> If you are prepared to fix userspace, tweaking the kernel not to install
> scratch pages everywhere is trivial.
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

I'll leave the further discussion of whether or not they still want all
the features to Paul (I think the synchronous unbinding execbuf is
useful regardless).

As for the trivial, "remove the scratch page" I didn't think that was
the plan as generally we'd like to carry on as long as possible, and we
know faults are fatal. I think keeping the scratch page, even if we
didn't have to worry about prefetching is what we want.

-- 
Ben Widawsky, Intel Open Source Technology Center

  reply	other threads:[~2013-06-28 23:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-28 22:23 [PATCH 0/6] Page faults to help user space debug Ben Widawsky
2013-06-28 22:23 ` [PATCH 1/6] drm/i915: Faults for scratch PTEs Ben Widawsky
2013-06-28 22:23 ` [PATCH 2/6] drm/i915: Debugfs for setting debug_flags Ben Widawsky
2013-06-28 22:23 ` [PATCH 3/6] drm/i915: Reset scratch pages when using debug_flags Ben Widawsky
2013-06-28 22:23 ` [PATCH 4/6] drm/i915: Synchronous execbuf for debug Ben Widawsky
2013-06-28 22:23 ` [PATCH 5/6] drm/i915: Let userspace create a faultable pad page Ben Widawsky
2013-06-28 22:23 ` [PATCH 6/6] drm/i915: distinguish pad and fault pages Ben Widawsky
2013-06-28 22:39 ` [PATCH 0/6] Page faults to help user space debug Chris Wilson
2013-06-28 23:30   ` Ben Widawsky [this message]
2013-06-29  7:02     ` Chris Wilson
2013-07-02 19:00   ` Paul Berry
2013-07-02 19:03     ` Chris Wilson
2013-07-02 19:18       ` Paul Berry
2013-07-06 20:11         ` Ben Widawsky
2013-07-02 19:04     ` Ben Widawsky
2013-06-29 14:38 ` Daniel Vetter
2013-06-29 21:20   ` Ben Widawsky
2013-06-29 21:28     ` 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=20130628233043.GA2141@bwidawsk.net \
    --to=ben@bwidawsk.net \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=stereotype441@gmail.com \
    /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