public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Ben Widawsky <ben@bwidawsk.net>
To: Paul Berry <stereotype441@gmail.com>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 0/6] Page faults to help user space debug
Date: Sat, 6 Jul 2013 13:11:34 -0700	[thread overview]
Message-ID: <20130706201134.GA32030@bwidawsk.net> (raw)
In-Reply-To: <CA+yLL66R1T0w_iTa_b9DCwk==nK0-KjqxKwxuNT4Uf_HVMrY5g@mail.gmail.com>

Can we get a collective status update? I'm touching some code at the
moment which will have some uncomfortable conflicts with this series,
and I'd like to have an idea on the plan.

On Tue, Jul 02, 2013 at 12:18:55PM -0700, Paul Berry wrote:
>    On 2 July 2013 12:03, Chris Wilson <[1]chris@chris-wilson.co.uk> wrote:
> 
>    On Tue, Jul 02, 2013 at 12:00:48PM -0700, Paul Berry wrote:
>    > Â  Â On 28 June 2013 15:39, Chris Wilson
>    <[1][2]chris@chris-wilson.co.uk> 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.
>    >
>    > Â  Â Mesa already adds the necessary padding to EU programs to ensure
>    that
>    > Â  Â prefetch won't cause a page fault, and because of its "stack and
>    heap"
>    > Â  Â model for batch buffers, CS prefetching shouldn't cause a page
>    fault
>    >    either.� I don't know whether the 2D drivers do something
>    similar, so they
>    > Â  Â might potentially need fixing.
> 
>      You do not on the BLT ring, and have not done historically. The EU
>      is no
>      longer padded. We have been purposely lax in this area.
> 
>    -Chris
> 
>    You're right--I didn't realize that we removed the EU padding, and I
>    wasn't thinking about the BLT code.
> 
> References
> 
>    1. mailto:chris@chris-wilson.co.uk
>    2. mailto:chris@chris-wilson.co.uk

-- 
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2013-07-06 20:08 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
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 [this message]
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=20130706201134.GA32030@bwidawsk.net \
    --to=ben@bwidawsk.net \
    --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