Re: [RFC] hung_task:add detecting task in D state milliseconds timeout

2020-07-06 Thread yang che
I will learn how to use KernelShark. Try to solve my problem,thanks for your suggestion. Talk about I solved a problem with hung task milliseconds: the process get anon_vma read lock when it directly reclaims memory, but other process down anon_vma write lock, long time waiting for write lock

Re: [RFC] hung_task:add detecting task in D state milliseconds timeout

2020-07-05 Thread Matthew Wilcox
On Fri, Jul 03, 2020 at 11:18:28AM +0800, yang che wrote: > my understanding, KernelShark can't trigger panic, hung_task can > trigger. According to my use, > sometimes need to trigger panic to grab ramdump to analyze lock and > memory problems. You shouldn't need to trigger a panic to analyse

Re: [RFC] hung_task:add detecting task in D state milliseconds timeout

2020-07-02 Thread yang che
my understanding, KernelShark can't trigger panic, hung_task can trigger. According to my use, sometimes need to trigger panic to grab ramdump to analyze lock and memory problems. So I want to increase this millisecond support. Matthew Wilcox 于2020年7月3日周五 上午1:43写道: > > On Thu, Jul 02, 2020 at

Re: [RFC] hung_task:add detecting task in D state milliseconds timeout

2020-07-02 Thread Matthew Wilcox
On Thu, Jul 02, 2020 at 10:08:13PM +0800, yang che wrote: > current hung_task_check_interval_secs and hung_task_timeout_secs > only supports seconds.in some cases,the TASK_UNINTERRUPTIBLE state > takes less than 1 second.The task of the graphical interface, > the unterruptible state lasts for

[RFC] hung_task:add detecting task in D state milliseconds timeout

2020-07-02 Thread yang che
current hung_task_check_interval_secs and hung_task_timeout_secs only supports seconds.in some cases,the TASK_UNINTERRUPTIBLE state takes less than 1 second.The task of the graphical interface, the unterruptible state lasts for hundreds of milliseconds will cause the interface to freeze echo 1 >