All of lore.kernel.org
 help / color / mirror / Atom feed
From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
To: Krzysztof Karas <krzysztof.karas@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	iommu@lists.linux.dev, "Andi Shyti" <andi.shyti@linux.intel.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Michał Grzelak" <michal.grzelak@intel.com>,
	"Sebastian Brzezinka" <sebastian.brzezinka@intel.com>,
	"Krzysztof Niemiec" <krzysztof.niemiec@intel.com>
Subject: Re: [PATCH v3 4/5] drm/i915/gem: Read and shrink memory in a separate function
Date: Mon, 20 Jul 2026 12:15:43 +0200	[thread overview]
Message-ID: <8154a1c3fedeb9b04df311ad92dc1db0de0a845e.camel@linux.intel.com> (raw)
In-Reply-To: <fpdox6uyoqnjx7nat427miehqtmhermzcpdpqfeystrmuwsgoq@sxbrby7ofmma>

On Mon, 2026-07-20 at 08:18 +0000, Krzysztof Karas wrote:
> Hi Janusz,
> 
> On 2026-07-15 at 17:31:56 +0200, Janusz Krzysztofik wrote:
> > On Mon, 2026-07-13 at 09:58 +0000, Krzysztof Karas wrote:
> > > Continue unloading shmem_sg_alloc_table by placing reading
> > > folios and shrink call into a new helper.
> > > Make the loop a bit more reader-friendly by removing iteration
> > > over a structure and replacing it with a do-while loop.
> > > 
> > > Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com>
> > > ---
> > > v3:
> > >  * Split refactoring and put it after the fix in shmem folio
> > >   counting suggested by Andi.
> > >  * Use do-while loop suggested by Robin. 
> > > 
> > >  drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 102 ++++++++++++----------
> > >  1 file changed, 55 insertions(+), 47 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > > index 4a61b012fb6f..7c8de8fe0a22 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > > @@ -78,6 +78,55 @@ static int validate_size(size_t size, unsigned int page_count,
> > >  	return 0;
> > >  }
> > >  
> > > +static struct folio *shmem_shrink_get_folio(struct address_space *mapping,
> > > +					    unsigned long folio_index,
> > > +					    gfp_t gfp, unsigned int page_count,
> > > +					    struct drm_i915_private *i915)
> > > +{
> > > +	struct folio *folio = NULL;
> > > +	unsigned int retries = 2;
> > > +
> > > +	do {
> > > +		cond_resched();
> > > +		folio = shmem_read_folio_gfp(mapping, folio_index, gfp);
> > > +		if (IS_ERR(folio)) {
> > 
> > Going again through then unused shrinking and modification of gfp doesn't 
> > make sense, I believe.  Could be avoided based on retries value as an 
> > additional condition.
> If calling i915_gem_shrink again doesn't give us anything, then
> looping doesn not really benefit us here. We could do something
> like this instead:
> 
> folio = shmem_read_folio_gfp(...);
> if (IS_ERR(folio)) {
> 	i915_gem_shrink(...);
> 	gfp = mapping_gfp_mask(mapping);
> 	gfp |= __GFP_RETRY_MAYFAIL | __GFP_NOWARN;
> 	/* again */
> 	folio = shmem_read_folio_gfp(...);
> }
> 
> return folio;
> 
> That way we'd be explicit about shrinking once and retrying
> folio reading only once. Reduced indentation would be added
> bonus.
> 
> What do you think?

Yes, that would be much more clear.  I would only keep the cond_resched(), 
at least before retrying, unless you can justify its removal.

Thanks,
Janusz

  reply	other threads:[~2026-07-20 10:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-13  9:58 [PATCH v3 0/5] drivers: Improve memory management for large object allocations when i915/shmem is used with iommu Krzysztof Karas
2026-07-13  9:58 ` [PATCH v3 1/5] drm/i915/gem: Count mapped pages in a folio Krzysztof Karas
2026-07-15 11:18   ` Janusz Krzysztofik
2026-07-20  8:08     ` Krzysztof Karas
2026-07-13  9:58 ` [PATCH v3 2/5] iommu/dma: Catch scatterlist length overflows Krzysztof Karas
2026-07-13 10:13   ` sashiko-bot
2026-07-16 12:39   ` Andi Shyti
2026-07-16 13:48   ` Robin Murphy
2026-07-20  7:46     ` Krzysztof Karas
2026-07-13  9:58 ` [PATCH v3 3/5] drm/i915/gem: Pull out size validation into a separate function Krzysztof Karas
2026-07-15 15:21   ` Janusz Krzysztofik
2026-07-20  8:10     ` Krzysztof Karas
2026-07-13  9:58 ` [PATCH v3 4/5] drm/i915/gem: Read and shrink memory in " Krzysztof Karas
2026-07-13 10:10   ` sashiko-bot
2026-07-15 15:31   ` Janusz Krzysztofik
2026-07-20  8:18     ` Krzysztof Karas
2026-07-20 10:15       ` Janusz Krzysztofik [this message]
2026-07-13  9:58 ` [PATCH v3 5/5] drm/i915/gem: Remove iterator and use while loop Krzysztof Karas
2026-07-13 10:09   ` sashiko-bot
2026-07-15 17:04   ` Janusz Krzysztofik
2026-07-20  8:25     ` Krzysztof Karas
2026-07-20 10:19       ` Janusz Krzysztofik
2026-07-13 11:01 ` ✓ i915.CI.BAT: success for drivers: Improve memory management for large object allocations when i915/shmem is used with iommu Patchwork
2026-07-13 14:14 ` ✗ i915.CI.Full: failure " Patchwork

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=8154a1c3fedeb9b04df311ad92dc1db0de0a845e.camel@linux.intel.com \
    --to=janusz.krzysztofik@linux.intel.com \
    --cc=andi.shyti@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=krzysztof.karas@intel.com \
    --cc=krzysztof.niemiec@intel.com \
    --cc=michal.grzelak@intel.com \
    --cc=robin.murphy@arm.com \
    --cc=sebastian.brzezinka@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.