On Fri, Oct 27, 2023 at 03:39:44PM +0200, Michael Grzeschik wrote:
On Fri, Oct 27, 2023 at 02:47:52PM +0300, Laurent Pinchart wrote:
> On Fri, Oct 27, 2023 at 01:10:21PM +0200, Michael Grzeschik wrote:
> > On Fri, Oct 27, 2023 at 10:51:17AM +0300, Laurent Pinchart wrote:
> > > On Thu, Oct 26, 2023 at 09:56:35PM +0000, Jayant Chowdhary wrote:
> > >> This patch is based on top of
> > >> https://lore.kernel.org/linux-usb/20230930184821.310143-1-arakesh@xxxxxxxxxx/T/#t:
> > >>
> > >> When we use an async work queue to perform the function of pumping
> > >> usb requests to the usb controller, it is possible that thread scheduling
> > >> affects at what cadence we're able to pump requests. This could mean usb
> > >> requests miss their uframes - resulting in video stream flickers on the host
> > >> device.
> > >>
> > >> In this patch, we move the pumping of usb requests to
> > >> 1) uvcg_video_complete() complete handler for both isoc + bulk
> > >> endpoints. We still send 0 length requests when there is no uvc buffer
> > >> available to encode.
> > >
> > > This means you will end up copying large amounts of data in interrupt
> > > context. The work queue was there to avoid exactly that, as it will
> > > introduce delays that can affect other parts of the system. I think this
> > > is a problem.
> >
> > Regarding Thin's argument about possible scheduling latency that is already
> > introducing real errors, this seemed like a good solution.
> >
> > But sure, this potential latency introduced in the interrupt context can
> > trigger other side effects.
> >
> > However I think we need some compromise since both arguments are very valid.
>
> Agreed.
>
> > Any ideas, how to solve this?
>
> I'm afraid not.
We discussed this and came to the conclusion that we could make use of
kthread_create and sched_setattr with an attr->sched_policy = SCHED_DEADLINE
here instead of the workqueue. This way we would ensure that the worker
would be triggered with hard definitions.
Since the SG case is not that heavy on the completion handler, we could
also make this kthread conditionaly to the memcpy case.
If you don't mind a naive suggestion from someone who knows nothing
about the driver...
An attractive possibility is to have the work queue (or kthread) do the
time-consuming copying, but leave the submission up to the completion
handler. If the data isn't ready (or there's no data to send) when the
handler runs, then queue a 0-length request.
That will give you the best of both worlds: low latency while in
interrupt context and a steady, constant flow of USB transfers at all
times. The question of how to schedule the work queue or kthread is a
separate matter, not directly relevant to this design decision.
Attachment:
signature.asc
Description: PGP signature