dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: "Christian König" <christian.koenig@amd.com>,
	intel-xe@lists.freedesktop.org
Cc: Somalapuram Amaranath <Amaranath.Somalapuram@amd.com>,
	Matthew Brost <matthew.brost@intel.com>,
	dri-devel@lists.freedesktop.org,
	Paulo Zanoni <paulo.r.zanoni@intel.com>,
	Simona Vetter <simona.vetter@ffwll.ch>
Subject: Re: [PATCH v14 3/8] drm/ttm/pool: Provide a helper to shrink pages
Date: Wed, 04 Dec 2024 13:24:10 +0100	[thread overview]
Message-ID: <4d71459d05a5b34acd3c911c80afbb52cc2cc527.camel@linux.intel.com> (raw)
In-Reply-To: <3130e373-5dbb-4f4b-a24c-a0015a638c3e@amd.com>

On Wed, 2024-12-04 at 12:24 +0100, Christian König wrote:
> Am 04.12.24 um 12:09 schrieb Thomas Hellström:
> > [SNIP]
> 
> > > > > BTW I really dislike that tt->restore is allocated
> > > > > dynamically.
> > > > > That
> > > > > is
> > > > > just another allocation which can cause problems.
> > > > > We should probably have all the state necessary for the
> > > > > operation
> > > > > in
> > > > > the
> > > > > TT object.
> > > > Initially it was done this way. But that meant a pre-allocated
> > > > struct
> > > > page-pointer array the of 1 << MAX_PAGE_ORDER size (2MiB) for
> > > > each
> > > > ttm_tt. That lead to a patch to reduce the MAX_PAGE_ORDER to
> > > > PMD
> > > > size
> > > > order, but  as you might remember, that needed to be ripped out
> > > > because
> > > > the PMD size macros aren't constant across all architectures.
> > > > IIRC
> > > > it
> > > > was ARM causing compilation failures, and Linus wasn't happy.
> > > Yeah, I do remember that. But I don't fully get why you need this
> > > page-pointer array in the first place?
> > So the TTM page-pointer array holds the backup handles when backed
> > up.
> > During recovery, We allocate a (potentially huge) page and populate
> > the
> > TTM page-pointer array with pointers into that. Meanwhile we need
> > to
> > keep the backup handles for the recover phase in the restore
> > structure,
> > and in the middle of the recover phase you might hit an -EINTR.
> 
> I still don't see the problem to be honest.
> 
> What you basically do on recovery is the following:
> 1. Allocate a bunch of contiguous memory of order X.
> 2. Take the first entry from the page_array, convert that to your
> backup 
> handle and copy the data back into the just allocated contiguous
> memory.
> 3. Replace the first entry in the page array with the struct page 
> pointer of the allocated contiguous memory.
> 4. Take the next entry from the page_array, convert that to your
> backup 
> handle and copy the data back into the just allocated contiguous
> memory.
> 5. Replace the next entry in the page_array with the struct page
> pointer 
> + 1 of the allocated contiguous memory.
> 6. Repeat until the contiguous memory is fully recovered and we jump
> to 
> 1 again.
> 
> What exactly do you need this pre-allocated struct page-pointer array
> of 
> 1 << MAX_PAGE_ORDER for?
> 
> Sorry, I must really be missing something here.

It was like a year or more ago since I put this patch together, so TBH
I can't recall the details, other than I'm pretty sure I tried that and
decided against it. Could have been that the changes were too invasive,
and it's pretty easy to break this code even without invasive
changes...

However with an accessor function for the old page pointers and one for
the new ones I imagine it should be possible.

I'll give it a try and see what can be done.

/Thomas


> 
> Regards,
> Christian.
> 
> > 
> > Thanks,
> > Thomas


  reply	other threads:[~2024-12-04 12:24 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-15 15:01 [PATCH v14 0/8] TTM shrinker helpers and xe buffer object shrinker Thomas Hellström
2024-11-15 15:01 ` [PATCH v14 1/8] drm/ttm: Balance ttm_resource_cursor_init() and ttm_resource_cursor_fini() Thomas Hellström
2024-11-20 10:51   ` Christian König
2024-11-21 15:54     ` Thomas Hellström
2024-11-15 15:01 ` [PATCH v14 2/8] drm/ttm: Provide a shmem backup implementation Thomas Hellström
2024-11-19 13:40   ` Christian König
2024-11-20  7:58     ` Thomas Hellström
2024-11-20  9:24       ` Christian König
2024-11-20 10:34         ` Thomas Hellström
2024-11-20 10:50           ` Christian König
2024-11-20 11:07             ` Thomas Hellström
2024-11-20 11:20         ` Thomas Hellström
2024-11-15 15:01 ` [PATCH v14 3/8] drm/ttm/pool: Provide a helper to shrink pages Thomas Hellström
2024-12-03 13:12   ` Christian König
2024-12-03 13:42     ` Thomas Hellström
2024-12-03 14:51       ` Christian König
2024-12-03 15:50         ` Thomas Hellström
2024-12-03 16:20           ` Christian König
2024-12-03 16:31             ` Thomas Hellström
2024-12-03 16:39               ` Christian König
2024-12-03 16:43                 ` Thomas Hellström
2024-12-03 16:46                   ` Christian König
2024-12-03 17:44                     ` Thomas Hellström
2024-12-04  9:16                       ` Christian König
2024-12-04  9:56                         ` Thomas Hellström
2024-12-04 10:56                           ` Christian König
2024-12-04 11:09                             ` Thomas Hellström
2024-12-04 11:24                               ` Christian König
2024-12-04 12:24                                 ` Thomas Hellström [this message]
2024-12-18 10:07                                 ` Thomas Hellström
2024-12-18 10:15         ` Thomas Hellström
2024-11-15 15:01 ` [PATCH v14 4/8] drm/ttm: Use fault-injection to test error paths Thomas Hellström
2024-11-15 15:01 ` [PATCH v14 5/8] drm/ttm: Add a macro to perform LRU iteration Thomas Hellström
2024-11-15 15:01 ` [PATCH v14 6/8] drm/ttm: Add helpers for shrinking Thomas Hellström
2024-11-15 15:01 ` [PATCH v14 7/8] drm/xe: Add a shrinker for xe bos Thomas Hellström
2024-11-15 15:01 ` [PATCH v14 8/8] drm/xe: Increase the XE_PL_TT watermark Thomas Hellström

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=4d71459d05a5b34acd3c911c80afbb52cc2cc527.camel@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=Amaranath.Somalapuram@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --cc=paulo.r.zanoni@intel.com \
    --cc=simona.vetter@ffwll.ch \
    /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