[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20f0c6fa-fb23-4159-b742-58994f2af30d@redhat.com>
Date: Sun, 29 Jun 2025 16:54:11 +0200
From: Danilo Krummrich <dakr@...hat.com>
To: Rob Clark <robin.clark@....qualcomm.com>
Cc: dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
linux-arm-msm@...r.kernel.org, Connor Abbott <cwabbott0@...il.com>,
Antonino Maniscalco <antomani103@...il.com>,
Dmitry Baryshkov <lumag@...nel.org>, Abhinav Kumar
<abhinav.kumar@...ux.dev>, Jessica Zhang <jessica.zhang@....qualcomm.com>,
Sean Paul <sean@...rly.run>, Marijn Suijten <marijn.suijten@...ainline.org>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Konrad Dybcio <konradybcio@...nel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v8 42/42] drm/msm: Add VM_BIND throttling
On 6/29/25 4:03 PM, Rob Clark wrote:
> @@ -1121,6 +1124,20 @@ vm_bind_prealloc_count(struct msm_vm_bind_job *job)
>
> /* Flush the remaining range: */
> prealloc_count(job, first, last);
> +
> + /*
> + * Now that we know the needed amount to pre-alloc, throttle on pending
> + * VM_BIND jobs if we already have too much pre-alloc memory in flight
> + */
> + ret = wait_event_interruptible(
> + to_msm_vm(job->vm)->sched.job_scheduled,
Ick! Please don't peek internal fields of the GPU scheduler (or any other API).
If you solve this within your driver for now, please use your own waitqueue
instead.
However, I think it would be even better to move this to a new generic
drm_throttle component as discussed in previous patches. We can also do this
subsequently though.
> + atomic_read(&job->queue->in_flight_prealloc) <= 1024);
> + if (ret)
> + return ret;
> +
> + atomic_add(job->prealloc.count, &job->queue->in_flight_prealloc);
> +
> + return 0;
> }
Powered by blists - more mailing lists