linux-kernel - Re: [PATCH] drm/vmwgfx: Replace schedule() with schedule

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CABQX2QMPJSV8-J+_A1aj+DbgQBbEXASq407-g+Q771+gsgZEDQ@mail.gmail.com>
Date: Wed, 29 Oct 2025 11:32:08 -0400
From: Zack Rusin <zack.rusin@...adcom.com>
To: opensource india <opensource206@...il.com>
Cc: maarten.lankhorst@...ux.intel.com, mripard@...nel.org, tzimmermann@...e.de, 
	airlied@...il.com, simona@...ll.ch, bcm-kernel-feedback-list@...adcom.com, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/vmwgfx: Replace schedule() with schedule_hrtimeout()
 in fallback wait

On Tue, Oct 28, 2025 at 7:06 AM opensource india
<opensource206@...il.com> wrote:
>
> Hi Zack Rusin,
>
> On Mon, Oct 20, 2025 at 9:48 AM Zack Rusin <zack.rusin@...adcom.com> wrote:
> >
>
> > I don't remember exactly the schedule family of functions but isn't
> > schedule_hrtimeout leaving the task in a running state? In general it
> > looks like with the patch the task's current state doesn't match what
> > was expected, plus I'm not sure if I quite get why the uninterruptible
> > non-lazy case is being replaced with a lazy wait of NSEC_PER_MSEC's.
> > It'd be great if you could explain a little bit better what you're
> > doing here because the commit message is missing an explanation for
> > either of those.
> >
> > z
>
> Thank you for checking the patch.
>
> The existing code does not specify any fixed wait time during the
> fence wait. It simply invokes schedule(),
> which means the task can be rescheduled immediately to check the fence
> status again.
>
> By using the high-resolution timer family of functions, we can specify
> an explicit sleep duration.
> In this patch, the sleep time is set to 1 ms, ensuring that the fence
> status is checked at fixed 1 ms intervals.
>
> This approach allows the CPU to be released to other tasks for a
> deterministic period,
> thereby reducing unnecessary CPU wakeups while maintaining timely
> fence checks(FIXME expected the same).

Sorry, but that doesn't answer any of my questions. I can see what the
patch is doing, but I'd love to know why. Same with the wait period:
why have you picked 1ms? To me that seems like introducing a huge
latency into fence waits, so I'd expect to see numbers that back it
up. What benchmarks have you run that show the CPU utilization and
FPS/score both before and after this patch that would justify that
wait period?

z

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5414 bytes)