On Wed, May 28, 2025 at 04:47:00PM +0200, Danilo Krummrich wrote:
> On Wed, May 28, 2025 at 04:39:01PM +0200, Danilo Krummrich wrote:
> > On Wed, May 28, 2025 at 09:29:30AM -0400, Alex Deucher wrote:
> > > On Wed, May 28, 2025 at 8:45 AM Simona Vetter
> > > wrote:
> > > > I do occasionally find i
On Wed, May 28, 2025 at 04:39:01PM +0200, Danilo Krummrich wrote:
> On Wed, May 28, 2025 at 09:29:30AM -0400, Alex Deucher wrote:
> > On Wed, May 28, 2025 at 8:45 AM Simona Vetter
> > wrote:
> > > I do occasionally find it useful as a record of different approaches
> > > considered, which sometim
On Wed, May 28, 2025 at 09:29:30AM -0400, Alex Deucher wrote:
> On Wed, May 28, 2025 at 8:45 AM Simona Vetter wrote:
> > I do occasionally find it useful as a record of different approaches
> > considered, which sometimes people fail to adequately cover in their
> > commit messages. Also useful in
On Wed, May 28, 2025 at 8:45 AM Simona Vetter wrote:
>
> On Mon, May 26, 2025 at 01:27:28PM +0200, Philipp Stanner wrote:
> > On Mon, 2025-05-26 at 13:16 +0200, Christian König wrote:
> > > On 5/26/25 11:34, Philipp Stanner wrote:
> > > > On Mon, 2025-05-26 at 11:25 +0200, Christian König wrote:
>
On 5/28/25 14:30, Simona Vetter wrote:
>> Yup, I've seen that a few times. I think we, the DRM community, should
>> stop that. It's just not useful and makes the commit messages larger,
>> both for the human reader while scrolling, as for the hard drive
>> regarding storage size
>
> I do occasiona
On Mon, May 26, 2025 at 01:27:28PM +0200, Philipp Stanner wrote:
> On Mon, 2025-05-26 at 13:16 +0200, Christian König wrote:
> > On 5/26/25 11:34, Philipp Stanner wrote:
> > > On Mon, 2025-05-26 at 11:25 +0200, Christian König wrote:
> > > > On 5/23/25 16:16, Danilo Krummrich wrote:
> > > > > On Fr
On Mon, 2025-05-26 at 11:25 +0200, Christian König wrote:
> On 5/23/25 16:16, Danilo Krummrich wrote:
> > On Fri, May 23, 2025 at 04:11:39PM +0200, Danilo Krummrich wrote:
> > > On Fri, May 23, 2025 at 02:56:40PM +0200, Christian König wrote:
> > > > It turned out that we can actually massively opt
On Mon, 2025-05-26 at 13:16 +0200, Christian König wrote:
> On 5/26/25 11:34, Philipp Stanner wrote:
> > On Mon, 2025-05-26 at 11:25 +0200, Christian König wrote:
> > > On 5/23/25 16:16, Danilo Krummrich wrote:
> > > > On Fri, May 23, 2025 at 04:11:39PM +0200, Danilo Krummrich
> > > > wrote:
> > >
+Cc Matthew, again :)
On Thu, 2025-05-22 at 18:19 +0200, Christian König wrote:
> On 5/22/25 16:27, Tvrtko Ursulin wrote:
> >
> > On 22/05/2025 14:41, Christian König wrote:
> > > Since we already iterated over the xarray we know at which index
> > > the new
> > > entry should be stored. So inste
On Fri, 2025-05-23 at 14:56 +0200, Christian König wrote:
> It turned out that we can actually massively optimize here.
>
> The previous code was horrible inefficient since it constantly
> released
> and re-acquired the lock of the xarray and started each iteration
> from the
> base of the array t
On 5/26/25 13:14, Danilo Krummrich wrote:
> (Cc: Matthew)
>
> Let's get this clarified to not work with assumptions. :)
>
> On Mon, May 26, 2025 at 12:59:41PM +0200, Christian König wrote:
>> On 5/24/25 13:17, Danilo Krummrich wrote:
>>> On Fri, May 23, 2025 at 04:11:39PM +0200, Danilo Krummrich
On 5/26/25 11:34, Philipp Stanner wrote:
> On Mon, 2025-05-26 at 11:25 +0200, Christian König wrote:
>> On 5/23/25 16:16, Danilo Krummrich wrote:
>>> On Fri, May 23, 2025 at 04:11:39PM +0200, Danilo Krummrich wrote:
On Fri, May 23, 2025 at 02:56:40PM +0200, Christian König wrote:
> It turn
(Cc: Matthew)
Let's get this clarified to not work with assumptions. :)
On Mon, May 26, 2025 at 12:59:41PM +0200, Christian König wrote:
> On 5/24/25 13:17, Danilo Krummrich wrote:
> > On Fri, May 23, 2025 at 04:11:39PM +0200, Danilo Krummrich wrote:
> > So, your code here should be correct. Howe
On 5/24/25 13:17, Danilo Krummrich wrote:
> On Fri, May 23, 2025 at 04:11:39PM +0200, Danilo Krummrich wrote:
>> On Fri, May 23, 2025 at 02:56:40PM +0200, Christian König wrote:
>>> + if (xas_nomem(&xas, GFP_KERNEL)) {
>>> + xa_lock(&job->dependencies);
>>> + goto retry;
>>
>>
On 5/23/25 16:16, Danilo Krummrich wrote:
> On Fri, May 23, 2025 at 04:11:39PM +0200, Danilo Krummrich wrote:
>> On Fri, May 23, 2025 at 02:56:40PM +0200, Christian König wrote:
>>> It turned out that we can actually massively optimize here.
>>>
>>> The previous code was horrible inefficient since
On Fri, May 23, 2025 at 04:11:39PM +0200, Danilo Krummrich wrote:
> On Fri, May 23, 2025 at 02:56:40PM +0200, Christian König wrote:
> > + if (xas_nomem(&xas, GFP_KERNEL)) {
> > + xa_lock(&job->dependencies);
> > + goto retry;
>
> Please don't use a goto here, if we would hav
On Fri, May 23, 2025 at 04:11:39PM +0200, Danilo Krummrich wrote:
> On Fri, May 23, 2025 at 02:56:40PM +0200, Christian König wrote:
> > It turned out that we can actually massively optimize here.
> >
> > The previous code was horrible inefficient since it constantly released
> > and re-acquired t
On Fri, May 23, 2025 at 02:56:40PM +0200, Christian König wrote:
> It turned out that we can actually massively optimize here.
>
> The previous code was horrible inefficient since it constantly released
> and re-acquired the lock of the xarray and started each iteration from the
> base of the arra
On 23/05/2025 13:56, Christian König wrote:
It turned out that we can actually massively optimize here.
The previous code was horrible inefficient since it constantly released
and re-acquired the lock of the xarray and started each iteration from the
base of the array to avoid concurrent modif
On 22/05/2025 17:19, Christian König wrote:
On 5/22/25 16:27, Tvrtko Ursulin wrote:
On 22/05/2025 14:41, Christian König wrote:
Since we already iterated over the xarray we know at which index the new
entry should be stored. So instead of using xa_alloc use xa_store and
write into the index
On 5/22/25 16:27, Tvrtko Ursulin wrote:
>
> On 22/05/2025 14:41, Christian König wrote:
>> Since we already iterated over the xarray we know at which index the new
>> entry should be stored. So instead of using xa_alloc use xa_store and
>> write into the index directly.
>>
>> Signed-off-by: Christ
On 22/05/2025 14:41, Christian König wrote:
Since we already iterated over the xarray we know at which index the new
entry should be stored. So instead of using xa_alloc use xa_store and
write into the index directly.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c
22 matches
Mail list logo
