All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas Stach <l.stach@pengutronix.de>
To: Russell King <linux@armlinux.org.uk>
Cc: dri-devel@lists.freedesktop.org, etnaviv@lists.freedesktop.org,
	kernel@pengutronix.de, patchwork-lst@pengutronix.de
Subject: Re: [PATCH] drm/etnaviv: bring back progress check in job timeout handler
Date: Tue, 03 Jul 2018 11:26:43 +0200	[thread overview]
Message-ID: <1530610003.22468.107.camel@pengutronix.de> (raw)
In-Reply-To: <20180627143427.25862-1-l.stach@pengutronix.de>

Hi Russell,

can you tell me if you will be able to provide some test feedback for
this patch during this week? I would like to get this into a fixes pull
towards the end of the week and would feel a bit more confident to do
so knowing that this really fixes the issue you are hitting on GC600.

Regards,
Lucas

Am Mittwoch, den 27.06.2018, 16:34 +0200 schrieb Lucas Stach:
> When the hangcheck handler was replaced by the DRM scheduler timeout
> handling we dropped the forward progress check, as this might allow
> clients to hog the GPU for a long time with a big job.
> 
> It turns out that even reasonably well behaved clients like the
> Armada Xorg driver occasionally trip over the 500ms timeout. Bring
> back the forward progress check to get rid of the userspace regression.
> 
> We would still like to fix userspace to submit smaller batches
> if possible, but that is for another day.
> 
> Fixes: 6d7a20c07760 (drm/etnaviv: replace hangcheck with scheduler timeout)
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h   |  3 +++
>  drivers/gpu/drm/etnaviv/etnaviv_sched.c | 24 ++++++++++++++++++++++++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> index dd430f0f8ff5..90f17ff7888e 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> @@ -131,6 +131,9 @@ struct etnaviv_gpu {
> >  	struct work_struct sync_point_work;
> >  	int sync_point_event;
>  
> > +	/* hang detection */
> > +	u32 hangcheck_dma_addr;
> +
> >  	void __iomem *mmio;
> >  	int irq;
>  
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> index a74eb57af15b..50d6b88cb7aa 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> @@ -10,6 +10,7 @@
>  #include "etnaviv_gem.h"
>  #include "etnaviv_gpu.h"
>  #include "etnaviv_sched.h"
> +#include "state.xml.h"
>  
>  static int etnaviv_job_hang_limit = 0;
>  module_param_named(job_hang_limit, etnaviv_job_hang_limit, int , 0444);
> @@ -85,6 +86,29 @@ static void etnaviv_sched_timedout_job(struct drm_sched_job *sched_job)
>  {
> >  	struct etnaviv_gem_submit *submit = to_etnaviv_submit(sched_job);
> >  	struct etnaviv_gpu *gpu = submit->gpu;
> > +	u32 dma_addr;
> > +	int change;
> +
> > +	/*
> > +	 * If the GPU managed to complete this jobs fence, the timout is
> > +	 * spurious. Bail out.
> > +	 */
> > +	if (fence_completed(gpu, submit->out_fence->seqno))
> > +		return;
> +
> > +	/*
> > +	 * If the GPU is still making forward progress on the front-end (which
> > +	 * should never loop) we shift out the timeout to give it a chance to
> > +	 * finish the job.
> > +	 */
> > +	dma_addr = gpu_read(gpu, VIVS_FE_DMA_ADDRESS);
> > +	change = dma_addr - gpu->hangcheck_dma_addr;
> > +	if (change < 0 || change > 16) {
> > +		gpu->hangcheck_dma_addr = dma_addr;
> > +		schedule_delayed_work(&sched_job->work_tdr,
> > +				      sched_job->sched->timeout);
> > +		return;
> > +	}
>  
> >  	/* block scheduler */
> >  	kthread_park(gpu->sched.thread);
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2018-07-03  9:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-27 14:34 [PATCH] drm/etnaviv: bring back progress check in job timeout handler Lucas Stach
2018-06-27 16:15 ` Fabio Estevam
2018-06-27 17:25 ` Eric Anholt
2018-06-28  8:40   ` Lucas Stach
2018-06-28 17:35     ` Eric Anholt
2018-07-03  9:26 ` Lucas Stach [this message]
2018-07-03  9:44 ` Russell King - ARM Linux
2018-07-03  9:54   ` Lucas Stach
2018-07-11 20:14 ` Russell King - ARM Linux

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=1530610003.22468.107.camel@pengutronix.de \
    --to=l.stach@pengutronix.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=etnaviv@lists.freedesktop.org \
    --cc=kernel@pengutronix.de \
    --cc=linux@armlinux.org.uk \
    --cc=patchwork-lst@pengutronix.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.