All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH] drm/xe: Replace the scratch pages with NULL PTEs
Date: Fri, 8 Dec 2023 12:19:28 +0100	[thread overview]
Message-ID: <eadb0ae0-fe72-aba0-9196-217bdcef8468@linux.intel.com> (raw)
In-Reply-To: <20231207163213.GZ5757@mdroper-desk1.amr.corp.intel.com>


On 12/7/23 17:32, Matt Roper wrote:
> On Thu, Dec 07, 2023 at 05:25:01PM +0100, Thomas Hellström wrote:
>> + intel-xe cc.
>>
>>
>> On 12/7/23 17:17, Lucas De Marchi wrote:
>>> On Thu, Dec 07, 2023 at 04:44:23PM +0100, Thomas Hellström wrote:
>>>> Replace the scratch pages with NULL PTEs that return 0 when reading and
>>>> do nothing when writing.
>>> but don't we want to keep scratch so we can check when things go wrong
>>> and writes go where they shouldn't?
>> The argument against that was that apps that incorrectly writes to scratch
>> and then reads back the same value wouldn't notice that it did something
>> wrong, and the case you mention would to some extent be captured by not
>> having a scratch page at all and check for pagefaults?
>>
>> I admit I haven't been following the discussions around scratch pages long
>> enough to know the historical uses for it. Cc'ing Joonas for further
>> discussion.
> It seems like null PTE is probably the best thing to do for real-world,
> production use.  But for developer use we might want to add a kconfig
> option at some point that brings back the scratch page and pre-poisons
> it, since that might be useful in some debugging situations.
>
>
> Matt

Hi, Matt.

Sounds like a good idea. IMO, Let's add that when we get a request for 
it for debugging purposes. I'll leave the scratch page-table structure 
in v2 so it should be easy to add in.

Thanks,

Thomas



  reply	other threads:[~2023-12-08 11:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 15:44 [PATCH] drm/xe: Replace the scratch pages with NULL PTEs Thomas Hellström
2023-12-07 16:17 ` Lucas De Marchi
2023-12-07 16:25   ` Thomas Hellström
2023-12-07 16:32     ` Matt Roper
2023-12-08 11:19       ` Thomas Hellström [this message]
2023-12-07 16:42     ` Lucas De Marchi
2023-12-07 17:10       ` Thomas Hellström
2023-12-07 17:39         ` Lucas De Marchi

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=eadb0ae0-fe72-aba0-9196-217bdcef8468@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.d.roper@intel.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 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.