[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7275ce3e432566e843e207b1d3dbbe82@mail.gmail.com>
Date: Tue, 12 Jun 2012 20:02:58 -0700
From: Sadasivan Shaiju <sshaiju@...sta.com>
To: Mandeep Baines <msb@...gle.com>, Daniel Walker <dwalker@...o99.com>
Cc: fweisbec@...il.com, mingo@...e.hu, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org
Subject: RE: hung_task checking and sys_sync
There was another patch addressing these type of issue .
https://lkml.org/lkml/2009/1/12/18
regards,
shaiju.
-----Original Message-----
From: Mandeep Baines [mailto:msb@...gle.com]
Sent: Tuesday, June 12, 2012 3:45 PM
To: Daniel Walker
Cc: fweisbec@...il.com; sshaiju@...sta.com; mingo@...e.hu;
akpm@...ux-foundation.org; linux-kernel@...r.kernel.org
Subject: Re: hung_task checking and sys_sync
On Tue, Jun 12, 2012 at 3:34 PM, Daniel Walker <dwalker@...o99.com> wrote:
> On Tue, Jun 12, 2012 at 03:29:12PM -0700, Mandeep Singh Baines wrote:
>>
>> But the time is not unbounded. You could mask the hung_task_detector
>> for this case but then you lose the ability to catch bugs in this code
path.
>>
>> The timeout is configurable via
/proc/sys/kernel/hung_task_timeout_secs.
>> Can you bump up the value at boot via sysctl.conf?
>
> Maybe, but I'm wondering if these types should just be stopped because
> Andrew had complained about them already.
>
Fair enough. Actually, internally I had a patch where we'd use a task flag
to disable and enable the hang check but the approach in the patch you
pointed me to seems better.
>> > Has there been any commit that disable these messages bdi_sched_wait?
>> >
>>
>> No. There is no mechanism to disable hung_task for a specific code
path.
>> We do skip processes if PF_PROZEN or PF_FROZEN_SKIP is set but that
>> is really a different situation where the wait is unbounded.
>
> There is presidence for this type of change,
>
> Author: Mark Lord <kernel@...savvy.com>
> Date: Fri Sep 24 09:51:13 2010 -0400
>
> block: Prevent hang_check firing during long I/O
>
> During long I/O operations, the hang_check timer may fire,
> trigger stack dumps that unnecessarily alarm the user.
>
> Eg. hdparm --security-erase NULL /dev/sdb ## can take *hours* to
> complete
>
> So, if hang_check is armed, we should wake up periodically
> to prevent it from triggering. This patch uses a wake-up interval
> equal to half the hang_check timer period, which keeps overhead low
enough.
>
> Signed-off-by: Mark Lord <mlord@...ox.com>
> Signed-off-by: Jens Axboe <jaxboe@...ionio.com>
>
Interesting. I wasn't aware of this patch. Maybe we could abstract this
approach via wait_for_completion_no_hang_check().
Regards,
Mandeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists