From: Boris Brezillon <boris.brezillon@collabora.com>
To: "Adrián Larumbe" <adrian.larumbe@collabora.com>
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, daniel@ffwll.ch,
robdclark@gmail.com, quic_abhinavk@quicinc.com,
dmitry.baryshkov@linaro.org, sean@poorly.run,
marijn.suijten@somainline.org, robh@kernel.org,
steven.price@arm.com, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
healych@amazon.com, kernel@collabora.com,
freedreno@lists.freedesktop.org
Subject: Re: [PATCH v2 3/6] drm/panfrost: Add fdinfo support for memory stats
Date: Wed, 30 Aug 2023 12:31:29 +0200 [thread overview]
Message-ID: <20230830122641.78d21f94@collabora.com> (raw)
In-Reply-To: <20230824013604.466224-4-adrian.larumbe@collabora.com>
On Thu, 24 Aug 2023 02:34:46 +0100
Adrián Larumbe <adrian.larumbe@collabora.com> wrote:
> A new DRM GEM object function is added so that drm_show_memory_stats can
> provider more accurate memory usage numbers.
s/provider/provide/
>
> Ideally, in panfrost_gem_status, the BO's purgeable flag would be checked
> after locking the driver's shrinker mutex, but drm_show_memory_stats takes
> over the drm file's object handle database spinlock, so there's potential
> for a race condition here.
Yeah, I don't think it matters much if we report a BO non-purgeable,
and this BO becomes purgeable in the meantime. You'd have the same
problem
>
> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 9 +++++++--
> drivers/gpu/drm/panfrost/panfrost_gem.c | 12 ++++++++++++
> drivers/gpu/drm/panfrost/panfrost_gem.h | 1 +
> 3 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 3fd372301019..93d5f5538c0b 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -440,11 +440,14 @@ static int panfrost_ioctl_madvise(struct drm_device *dev, void *data,
> args->retained = drm_gem_shmem_madvise(&bo->base, args->madv);
>
> if (args->retained) {
> - if (args->madv == PANFROST_MADV_DONTNEED)
> + if (args->madv == PANFROST_MADV_DONTNEED) {
> list_move_tail(&bo->base.madv_list,
> &pfdev->shrinker_list);
> - else if (args->madv == PANFROST_MADV_WILLNEED)
> + bo->is_purgable = true;
> + } else if (args->madv == PANFROST_MADV_WILLNEED) {
> list_del_init(&bo->base.madv_list);
> + bo->is_purgable = false;
Should we really flag the BO as purgeable if it's already been evicted
(args->retained == false)?
> + }
> }
>
> out_unlock_mappings:
> @@ -559,6 +562,8 @@ static void panfrost_show_fdinfo(struct drm_printer *p, struct drm_file *file)
> struct panfrost_device *pfdev = dev->dev_private;
>
> panfrost_gpu_show_fdinfo(pfdev, file->driver_priv, p);
> +
> + drm_show_memory_stats(p, file);
> }
>
> static const struct file_operations panfrost_drm_driver_fops = {
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index 3c812fbd126f..aea16b0e4dda 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -195,6 +195,17 @@ static int panfrost_gem_pin(struct drm_gem_object *obj)
> return drm_gem_shmem_pin(&bo->base);
> }
>
> +static enum drm_gem_object_status panfrost_gem_status(struct drm_gem_object *obj)
> +{
> + struct panfrost_gem_object *bo = to_panfrost_bo(obj);
> + enum drm_gem_object_status res = 0;
> +
> + res |= (bo->is_purgable) ? DRM_GEM_OBJECT_PURGEABLE : 0;
Why not checking bo->base.madv here instead of adding an is_purgeable
field?
> +
> + res |= (bo->base.pages) ? DRM_GEM_OBJECT_RESIDENT : 0;
Does it make sense to have DRM_GEM_OBJECT_PURGEABLE set when
DRM_GEM_OBJECT_RESIDENT is not?
> +
> + return res;
> +}
> static const struct drm_gem_object_funcs panfrost_gem_funcs = {
> .free = panfrost_gem_free_object,
> .open = panfrost_gem_open,
> @@ -206,6 +217,7 @@ static const struct drm_gem_object_funcs panfrost_gem_funcs = {
> .vmap = drm_gem_shmem_object_vmap,
> .vunmap = drm_gem_shmem_object_vunmap,
> .mmap = drm_gem_shmem_object_mmap,
> + .status = panfrost_gem_status,
> .vm_ops = &drm_gem_shmem_vm_ops,
> };
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h b/drivers/gpu/drm/panfrost/panfrost_gem.h
> index ad2877eeeccd..e06f7ceb8f73 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
> @@ -38,6 +38,7 @@ struct panfrost_gem_object {
>
> bool noexec :1;
> bool is_heap :1;
> + bool is_purgable :1;
> };
>
> struct panfrost_gem_mapping {
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: "Adrián Larumbe" <adrian.larumbe@collabora.com>
Cc: tzimmermann@suse.de, sean@poorly.run, quic_abhinavk@quicinc.com,
mripard@kernel.org, steven.price@arm.com,
freedreno@lists.freedesktop.org, healych@amazon.com,
dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
dmitry.baryshkov@linaro.org, marijn.suijten@somainline.org,
kernel@collabora.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/6] drm/panfrost: Add fdinfo support for memory stats
Date: Wed, 30 Aug 2023 12:31:29 +0200 [thread overview]
Message-ID: <20230830122641.78d21f94@collabora.com> (raw)
In-Reply-To: <20230824013604.466224-4-adrian.larumbe@collabora.com>
On Thu, 24 Aug 2023 02:34:46 +0100
Adrián Larumbe <adrian.larumbe@collabora.com> wrote:
> A new DRM GEM object function is added so that drm_show_memory_stats can
> provider more accurate memory usage numbers.
s/provider/provide/
>
> Ideally, in panfrost_gem_status, the BO's purgeable flag would be checked
> after locking the driver's shrinker mutex, but drm_show_memory_stats takes
> over the drm file's object handle database spinlock, so there's potential
> for a race condition here.
Yeah, I don't think it matters much if we report a BO non-purgeable,
and this BO becomes purgeable in the meantime. You'd have the same
problem
>
> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 9 +++++++--
> drivers/gpu/drm/panfrost/panfrost_gem.c | 12 ++++++++++++
> drivers/gpu/drm/panfrost/panfrost_gem.h | 1 +
> 3 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 3fd372301019..93d5f5538c0b 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -440,11 +440,14 @@ static int panfrost_ioctl_madvise(struct drm_device *dev, void *data,
> args->retained = drm_gem_shmem_madvise(&bo->base, args->madv);
>
> if (args->retained) {
> - if (args->madv == PANFROST_MADV_DONTNEED)
> + if (args->madv == PANFROST_MADV_DONTNEED) {
> list_move_tail(&bo->base.madv_list,
> &pfdev->shrinker_list);
> - else if (args->madv == PANFROST_MADV_WILLNEED)
> + bo->is_purgable = true;
> + } else if (args->madv == PANFROST_MADV_WILLNEED) {
> list_del_init(&bo->base.madv_list);
> + bo->is_purgable = false;
Should we really flag the BO as purgeable if it's already been evicted
(args->retained == false)?
> + }
> }
>
> out_unlock_mappings:
> @@ -559,6 +562,8 @@ static void panfrost_show_fdinfo(struct drm_printer *p, struct drm_file *file)
> struct panfrost_device *pfdev = dev->dev_private;
>
> panfrost_gpu_show_fdinfo(pfdev, file->driver_priv, p);
> +
> + drm_show_memory_stats(p, file);
> }
>
> static const struct file_operations panfrost_drm_driver_fops = {
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index 3c812fbd126f..aea16b0e4dda 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -195,6 +195,17 @@ static int panfrost_gem_pin(struct drm_gem_object *obj)
> return drm_gem_shmem_pin(&bo->base);
> }
>
> +static enum drm_gem_object_status panfrost_gem_status(struct drm_gem_object *obj)
> +{
> + struct panfrost_gem_object *bo = to_panfrost_bo(obj);
> + enum drm_gem_object_status res = 0;
> +
> + res |= (bo->is_purgable) ? DRM_GEM_OBJECT_PURGEABLE : 0;
Why not checking bo->base.madv here instead of adding an is_purgeable
field?
> +
> + res |= (bo->base.pages) ? DRM_GEM_OBJECT_RESIDENT : 0;
Does it make sense to have DRM_GEM_OBJECT_PURGEABLE set when
DRM_GEM_OBJECT_RESIDENT is not?
> +
> + return res;
> +}
> static const struct drm_gem_object_funcs panfrost_gem_funcs = {
> .free = panfrost_gem_free_object,
> .open = panfrost_gem_open,
> @@ -206,6 +217,7 @@ static const struct drm_gem_object_funcs panfrost_gem_funcs = {
> .vmap = drm_gem_shmem_object_vmap,
> .vunmap = drm_gem_shmem_object_vunmap,
> .mmap = drm_gem_shmem_object_mmap,
> + .status = panfrost_gem_status,
> .vm_ops = &drm_gem_shmem_vm_ops,
> };
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h b/drivers/gpu/drm/panfrost/panfrost_gem.h
> index ad2877eeeccd..e06f7ceb8f73 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
> @@ -38,6 +38,7 @@ struct panfrost_gem_object {
>
> bool noexec :1;
> bool is_heap :1;
> + bool is_purgable :1;
> };
>
> struct panfrost_gem_mapping {
next prev parent reply other threads:[~2023-08-30 18:31 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 1:34 [PATCH v2 0/6] Add fdinfo support to Panfrost Adrián Larumbe
2023-08-24 1:34 ` Adrián Larumbe
2023-08-24 1:34 ` [PATCH v2 1/6] drm/panfrost: Add cycle count GPU register definitions Adrián Larumbe
2023-08-24 1:34 ` Adrián Larumbe
2023-08-30 10:35 ` Boris Brezillon
2023-08-30 10:35 ` Boris Brezillon
2023-08-31 15:54 ` Steven Price
2023-08-31 15:54 ` Steven Price
2023-08-24 1:34 ` [PATCH v2 2/6] drm/panfrost: Add fdinfo support GPU load metrics Adrián Larumbe
2023-08-24 1:34 ` Adrián Larumbe
2023-08-24 4:12 ` kernel test robot
2023-08-24 4:12 ` kernel test robot
2023-08-30 10:17 ` Boris Brezillon
2023-08-30 10:17 ` Boris Brezillon
2023-08-31 23:23 ` Adrián Larumbe
2023-08-31 23:23 ` Adrián Larumbe
2023-08-31 15:54 ` Steven Price
2023-08-31 15:54 ` Steven Price
2023-08-31 21:34 ` Adrián Larumbe
2023-08-31 21:34 ` Adrián Larumbe
2023-09-04 8:22 ` Steven Price
2023-09-04 8:22 ` Steven Price
2023-09-02 3:20 ` kernel test robot
2023-09-02 3:20 ` kernel test robot
2023-08-24 1:34 ` [PATCH v2 3/6] drm/panfrost: Add fdinfo support for memory stats Adrián Larumbe
2023-08-24 1:34 ` Adrián Larumbe
2023-08-30 10:31 ` Boris Brezillon [this message]
2023-08-30 10:31 ` Boris Brezillon
2023-08-31 23:07 ` Adrián Larumbe
2023-08-31 23:07 ` Adrián Larumbe
2023-08-24 1:34 ` [PATCH v2 4/6] drm/drm_file: Add DRM obj's RSS reporting function for fdinfo Adrián Larumbe
2023-08-24 1:34 ` Adrián Larumbe
2023-08-30 10:34 ` Boris Brezillon
2023-08-30 10:34 ` Boris Brezillon
2023-08-24 1:34 ` [PATCH v2 5/6] drm/panfrost: Implement generic DRM object RSS reporting function Adrián Larumbe
2023-08-24 1:34 ` Adrián Larumbe
2023-08-24 11:13 ` kernel test robot
2023-08-24 11:13 ` kernel test robot
2023-08-30 10:52 ` Boris Brezillon
2023-08-30 10:52 ` Boris Brezillon
2023-09-01 0:03 ` Adrián Larumbe
2023-09-01 0:03 ` Adrián Larumbe
2023-09-01 6:44 ` Boris Brezillon
2023-09-01 6:44 ` Boris Brezillon
2023-08-24 1:34 ` [PATCH v2 6/6] drm/drm-file: Allow size unit selection in drm_show_memory_stats Adrián Larumbe
2023-08-24 1:34 ` Adrián Larumbe
2023-08-24 6:49 ` kernel test robot
2023-08-24 6:49 ` kernel test robot
2023-08-28 15:00 ` Rob Clark
2023-08-28 15:00 ` Rob Clark
2023-08-30 15:51 ` Adrián Larumbe
2023-08-30 15:51 ` Adrián Larumbe
2023-09-05 22:23 ` Rob Clark
2023-09-05 22:23 ` Rob Clark
2023-09-01 22:18 ` kernel test robot
2023-09-01 22:18 ` kernel test robot
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=20230830122641.78d21f94@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=adrian.larumbe@collabora.com \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=healych@amazon.com \
--cc=kernel@collabora.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marijn.suijten@somainline.org \
--cc=mripard@kernel.org \
--cc=quic_abhinavk@quicinc.com \
--cc=robdclark@gmail.com \
--cc=robh@kernel.org \
--cc=sean@poorly.run \
--cc=steven.price@arm.com \
--cc=tzimmermann@suse.de \
/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.