From: Imran Khan <kimran@codeaurora.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@kernel.org, imrank140517@gmail.com,
"Luis R. Rodriguez" <mcgrof@kernel.org>,
Kees Cook <keescook@chromium.org>,
Shile Zhang <shile.zhang@nokia.com>,
Matt Fleming <matt@codeblueprint.co.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Vegard Nossum <vegard.nossum@oracle.com>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
John Siddle <jsiddle@redhat.com>,
open list <linux-kernel@vger.kernel.org>,
"open list:PROC SYSCTL" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] RFC: hung task: Check specific tasks for long uninterruptible sleep state
Date: Wed, 23 Aug 2017 17:55:46 +0530 [thread overview]
Message-ID: <b65cf7ff-8834-879a-bb51-5ad8e6f20126@codeaurora.org> (raw)
In-Reply-To: <20170822203632.GQ32112@worktop.programming.kicks-ass.net>
On 8/23/2017 2:06 AM, Peter Zijlstra wrote:
> On Mon, Aug 21, 2017 at 03:55:53PM +0530, Imran Khan wrote:
>> khungtask by default monitors either all tasks or no tasks at all
>> for long unterruptible sleeps.
>> For Android like environments this arrangement is not optimal because
>> on one hand it may be permissible to have some background(bg) task
>> in uninterruptible sleep state for long duration while on the other
>> hand it may not be permissible to have some foreground(fg) task like
>> surfaceflinger in uninterruptible sleep state for long duration.
>
> How are you getting tasks in UNINTERRUPTIBLE state for a long time to
> begin with? That's not a good thing, background or not.
>
As of now, I don't have the details of exact test case as most of these issues are
coming in android aging and stress tests but I see even in a non-android
setup I get few tasks in uninterruptible sleep state for long duration (60 secs).
For example, I see there is a thread waiting for mmc requests to appear from block
layer. Of course this can be a faulty design on the driver side too but my main
intention here is to know if we can enable/disable this monitoring for
specific tasks and whether such an option would be useful and agreeable to
community or not.
Also in current scheme of things we use same timeout for all tasks which may
not be optimal. For example if some task is in disk sleep state it may be okay
for it to wait for 2 minutes but if surfaceflinger (android) is stuck even for
1 minute, it results in a very poor UI experience for user of the phone.
>> So it would be good to have some arrangement so that few specified tasks
>> can be monitored by khungtaskd, on a need basis.
>> This change introduces a sysctl option, /proc/sys/kernel/
>> hung_task_check_selected, to enable monitoring of selected tasks using
>> khungtask daemon. If this sysctl option is enabled then only the tasks
>> specified in /proc/hung_task_monitor_list are monitored otherwise all
>> tasks are monitored, just like the default case.
>
> That's horrible. Why not a file in /proc/$PID/ that excludes it from
> things?
>
To be honest, I also had apprehension about my approach and did not think
it through. I agree that /proc/$PID/ based approach is much better. If it is
agreed that selective monitoring of hung tasks has valid use case(s), I can
send the /proc/$PID based patch for review.
Thanks for your time and feedback.
Regards,
Imran
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2017-08-23 12:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-21 10:25 Imran Khan
2017-08-22 1:54 ` Zhang, Shile (NSB - CN/Hangzhou)
2017-08-22 6:03 ` Imran Khan
2017-08-22 6:49 ` Zhang, Shile (NSB - CN/Hangzhou)
2017-08-22 20:36 ` Peter Zijlstra
2017-08-23 12:25 ` Imran Khan [this message]
2017-11-08 6:28 ` [RFC] hung task: check " Lingutla Chandrasekhar
2017-11-08 11:57 ` Tetsuo Handa
2017-11-08 23:44 ` Andrew Morton
2017-11-09 1:54 ` Luis R. Rodriguez
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=b65cf7ff-8834-879a-bb51-5ad8e6f20126@codeaurora.org \
--to=kimran@codeaurora.org \
--cc=akpm@linux-foundation.org \
--cc=imrank140517@gmail.com \
--cc=jsiddle@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mcgrof@kernel.org \
--cc=mingo@kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=peterz@infradead.org \
--cc=shile.zhang@nokia.com \
--cc=vegard.nossum@oracle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome