All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Abhinav Kumar <quic_abhinavk@quicinc.com>
Cc: johannes@sipsolutions.net, linux-kernel@vger.kernel.org,
	rafael@kernel.org, robdclark@gmail.com,
	dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	freedreno@lists.freedesktop.org, seanpaul@chromium.org,
	swboyd@chromium.org, nganji@codeaurora.org,
	aravindh@codeaurora.org, khsieh@codeaurora.org, daniel@ffwll.ch,
	dmitry.baryshkov@linaro.org
Subject: Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins
Date: Sat, 12 Feb 2022 08:04:11 +0100	[thread overview]
Message-ID: <Ygdb63FrorUsX/Hg@kroah.com> (raw)
In-Reply-To: <654d620b-9e14-c47f-b48c-762dc0bd32a1@quicinc.com>

On Fri, Feb 11, 2022 at 10:59:39AM -0800, Abhinav Kumar wrote:
> Hi Greg
> 
> Thanks for the response.
> 
> On 2/11/2022 3:09 AM, Greg KH wrote:
> > On Tue, Feb 08, 2022 at 11:44:32AM -0800, Abhinav Kumar wrote:
> > > There are cases where depending on the size of the devcoredump and the speed
> > > at which the usermode reads the dump, it can take longer than the current 5 mins
> > > timeout.
> > > 
> > > This can lead to incomplete dumps as the device is deleted once the timeout expires.
> > > 
> > > One example is below where it took 6 mins for the devcoredump to be completely read.
> > > 
> > > 04:22:24.668 23916 23994 I HWDeviceDRM::DumpDebugData: Opening /sys/class/devcoredump/devcd6/data
> > > 04:28:35.377 23916 23994 W HWDeviceDRM::DumpDebugData: Freeing devcoredump node
> > 
> > What makes this so slow?  Reading from the kernel shouldn't be the
> > limit, is it where the data is being sent to?
> 
> We are still checking this. We are seeing better read times when we bump up
> the thread priority of the thread which was reading this.

Where is the thread sending the data to?

> We are also trying to check if bumping up CPU speed is helping.
> But, results have not been consistently good enough. So we thought we should
> also increase the timeout to be safe.

Why would 10 minutes be better than 30?  What should the limit be?  :)

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Abhinav Kumar <quic_abhinavk@quicinc.com>
Cc: rafael@kernel.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	swboyd@chromium.org, khsieh@codeaurora.org,
	nganji@codeaurora.org, seanpaul@chromium.org,
	dmitry.baryshkov@linaro.org, johannes@sipsolutions.net,
	aravindh@codeaurora.org, freedreno@lists.freedesktop.org
Subject: Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins
Date: Sat, 12 Feb 2022 08:04:11 +0100	[thread overview]
Message-ID: <Ygdb63FrorUsX/Hg@kroah.com> (raw)
In-Reply-To: <654d620b-9e14-c47f-b48c-762dc0bd32a1@quicinc.com>

On Fri, Feb 11, 2022 at 10:59:39AM -0800, Abhinav Kumar wrote:
> Hi Greg
> 
> Thanks for the response.
> 
> On 2/11/2022 3:09 AM, Greg KH wrote:
> > On Tue, Feb 08, 2022 at 11:44:32AM -0800, Abhinav Kumar wrote:
> > > There are cases where depending on the size of the devcoredump and the speed
> > > at which the usermode reads the dump, it can take longer than the current 5 mins
> > > timeout.
> > > 
> > > This can lead to incomplete dumps as the device is deleted once the timeout expires.
> > > 
> > > One example is below where it took 6 mins for the devcoredump to be completely read.
> > > 
> > > 04:22:24.668 23916 23994 I HWDeviceDRM::DumpDebugData: Opening /sys/class/devcoredump/devcd6/data
> > > 04:28:35.377 23916 23994 W HWDeviceDRM::DumpDebugData: Freeing devcoredump node
> > 
> > What makes this so slow?  Reading from the kernel shouldn't be the
> > limit, is it where the data is being sent to?
> 
> We are still checking this. We are seeing better read times when we bump up
> the thread priority of the thread which was reading this.

Where is the thread sending the data to?

> We are also trying to check if bumping up CPU speed is helping.
> But, results have not been consistently good enough. So we thought we should
> also increase the timeout to be safe.

Why would 10 minutes be better than 30?  What should the limit be?  :)

thanks,

greg k-h

  reply	other threads:[~2022-02-12  7:04 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-08 19:44 [PATCH] devcoredump: increase the device delete timeout to 10 mins Abhinav Kumar
2022-02-08 19:44 ` Abhinav Kumar
2022-02-08 20:35 ` Johannes Berg
2022-02-08 20:35   ` Johannes Berg
2022-02-08 21:04   ` Abhinav Kumar
2022-02-08 21:04     ` Abhinav Kumar
2022-02-08 21:12     ` Johannes Berg
2022-02-08 21:12       ` Johannes Berg
2022-02-08 21:40       ` Abhinav Kumar
2022-02-08 21:40         ` Abhinav Kumar
2022-02-08 21:54         ` Johannes Berg
2022-02-09  1:55           ` Abhinav Kumar
2022-02-09  1:55             ` Abhinav Kumar
2022-02-09  7:50             ` Johannes Berg
2022-02-09 16:29               ` Abhinav Kumar
2022-02-09 16:29                 ` Abhinav Kumar
2022-02-11 11:09             ` Greg KH
2022-02-11 11:09               ` Greg KH
2022-02-11 11:09 ` Greg KH
2022-02-11 11:09   ` Greg KH
2022-02-11 18:59   ` Abhinav Kumar
2022-02-11 18:59     ` Abhinav Kumar
2022-02-12  7:04     ` Greg KH [this message]
2022-02-12  7:04       ` Greg KH
2022-02-12  7:52       ` Abhinav Kumar
2022-02-12  7:52         ` Abhinav Kumar
2022-02-12  8:24         ` Johannes Berg
2022-02-12  8:24           ` Johannes Berg
2022-02-12  8:35           ` Abhinav Kumar
2022-02-12  8:35             ` Abhinav Kumar
2022-02-28 21:38             ` Abhinav Kumar
2022-02-28 21:38               ` Abhinav Kumar
2022-03-01  6:48               ` David Laight
2022-03-01 17:45                 ` Rob Clark
2022-03-01 17:45                   ` Rob Clark
2022-03-11 11:53                   ` Johannes Berg
2022-03-11 11:53                     ` Johannes Berg
2022-02-12  8:29         ` Greg KH
2022-02-12  8:29           ` Greg KH
2022-02-12  8:33           ` Abhinav Kumar
2022-02-12  8:33             ` Abhinav Kumar

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=Ygdb63FrorUsX/Hg@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=aravindh@codeaurora.org \
    --cc=daniel@ffwll.ch \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=johannes@sipsolutions.net \
    --cc=khsieh@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nganji@codeaurora.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=rafael@kernel.org \
    --cc=robdclark@gmail.com \
    --cc=seanpaul@chromium.org \
    --cc=swboyd@chromium.org \
    /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.