From: sashiko-bot@kernel.org
To: "Matthew Brost" <matthew.brost@intel.com>
Cc: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [RFC PATCH] drm/exec: track the first few locked objects inline
Date: Fri, 02 Oct 2026 09:14:23 +0000 [thread overview]
Message-ID: <20261002091424.BABE31F00893@smtp.kernel.org> (raw)
In-Reply-To: <20261002003816.3233277-1-matthew.brost@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm: memory waste in drm_exec due to unaligned kvmalloc size
--
commit c9e9f41b6b460bbc9dee72fd6820d00dc1915559
Author: Matthew Brost <matthew.brost@intel.com>
drm/exec: track the first few locked objects inline
This commit adds tracking for the first few locked objects inline within
the drm_exec structure. This avoids early allocations and prevents
-ENOMEM failures on paths that only need to lock a few objects.
Link: https://sashiko.dev/#/patchset/20261001220632.3190896-1-matthew.brost%40intel.com
> diff --git a/drivers/gpu/drm/drm_exec.c b/drivers/gpu/drm/drm_exec.c
> --- a/drivers/gpu/drm/drm_exec.c
> +++ b/drivers/gpu/drm/drm_exec.c
[ ... ]
> @@ -140,9 +148,16 @@ static int drm_exec_obj_locked(struct drm_exec *exec,
> {
> if (unlikely(exec->num_objects == exec->max_objects)) {
> size_t size = exec->max_objects * sizeof(void *);
> - void *tmp;
> -
> - tmp = kvrealloc(exec->objects, size + PAGE_SIZE, GFP_KERNEL);
> + struct drm_gem_object **tmp;
> +
> + if (exec->objects == exec->inline_objects) {
> + tmp = kvmalloc(size + PAGE_SIZE, GFP_KERNEL);
[Severity: Medium]
When falling back from the inline storage, size is 64 bytes (8 pointers).
The code requests kvmalloc(64 + 4096), which is 4160 bytes. Does this
cause the slab allocator to round up to the kmalloc-8k cache, wasting
nearly half the allocation?
> + if (tmp)
> + memcpy(tmp, exec->objects, size);
> + } else {
> + tmp = kvrealloc(exec->objects, size + PAGE_SIZE,
> + GFP_KERNEL);
> + }
> if (!tmp)
> return -ENOMEM;
>
> exec->objects = tmp;
> exec->max_objects += PAGE_SIZE / sizeof(void *);
[Severity: Medium]
Since max_objects started at 8, adding PAGE_SIZE / sizeof(void *) makes
max_objects 520. When the array grows again, size will be 4160 and
kvrealloc will request 8256 bytes, forcing kmalloc-16k. Does this continue
to waste memory at every growth step because the total object count remains
unaligned to the page size?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261002003816.3233277-1-matthew.brost@intel.com?part=1
next prev parent reply other threads:[~2026-10-02 9:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 0:38 [RFC PATCH] drm/exec: track the first few locked objects inline Matthew Brost
2026-10-02 0:46 ` ✓ CI.KUnit: success for " Patchwork
2026-10-02 9:14 ` sashiko-bot [this message]
2026-10-02 11:35 ` [RFC PATCH] " Christian König
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=20261002091424.BABE31F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=sashiko-reviews@lists.linux.dev \
/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