On Thu, May 04, 2017 at 02:13:40PM +0300, Alex Lyakas wrote: > Hello, > > > # it is still not clear who is holding the lock > Further analysis shows that the xfs_buf lock is being held, because > the buffer is currently being read from disk. The stack that unlocks > the buffer is [1]. The size of each buffer being read is 4Kb. > > So bottom line is that sometimes XFS needs to search through thousands > of metadata blocks of 4Kb, and needs to wait while they are being read > from disk. This causes very slow allocation in some cases, further > causing other threads to wait on i_lock/i_mutex, in some cases > triggering hung-task panics. > Not that this helps resolve the fundamental problem, but note that I don't think hung task messages have to result in kernel panics. On a quick look at v3.18, the CONFIG_BOOTPARAM_HUNG_TASK_PANIC kernel config option looks like it determines whether a hung task message panics the kernel or not. Brian > Anything can be done to remedy this? > > Thanks, > Alex. > > > > [1] > Call Trace: > [<ffffffff81710c85>] dump_stack+0x4e/0x71 > [<ffffffffc0fade1b>] xfs_buf_ioend+0x22b/0x230 [xfs] > [<ffffffffc0fade35>] xfs_buf_ioend_work+0x15/0x20 [xfs] > [<ffffffff8108bd56>] process_one_work+0x146/0x410 > [<ffffffff8108c141>] worker_thread+0x121/0x450 > [<ffffffff8108c020>] ? process_one_work+0x410/0x410 > [<ffffffff810911b9>] kthread+0xc9/0xe0 > [<ffffffff810910f0>] ? kthread_create_on_node+0x180/0x180 > [<ffffffff81717918>] ret_from_fork+0x58/0x90 > [<ffffffff810910f0>] ? kthread_create_on_node+0x180/0x180 > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
