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
