On 2011.06.21 at 20:57 +0200, Markus Trippelsdorf wrote: > On 2011.06.21 at 20:24 +0200, Markus Trippelsdorf wrote: > > On 2011.06.21 at 10:02 +0200, Markus Trippelsdorf wrote: > > > On 2011.06.21 at 14:25 +1000, Dave Chinner wrote: > > > > That is, you really need to get a profile of the rm -rf process - or > > > > whatever is consuming the CPU time - (e.g. via perf or ftrace) > > > > across the hang to so we can narrow down the potential cause of the > > > > latency. Speaking of which, latencytop might be helpful in > > > > identifying where input is getting held up.... > > > > > > I've recorded a profile with "perf record -g /home/markus/rm_sync" > > > ~ % cat rm_sync > > > rm -fr /mnt/tmp/tmp/linux && sync > > > > FWIW here are two links to svg time-charts produced by: > > > > perf timechart record /home/markus/rm_sync > > > > http://trippelsdorf.de/timechart1.svg > > http://trippelsdorf.de/timechart2.svg > > > > And this is what the mysterious kworker is doing during the sync. > It's the one consuming most of the CPU time. > > 39.96% kworker/3:0 [kernel.kallsyms] 0xffffffff811da9da k [k] xfs_trans_ail_update_bulk > | > --- xfs_trans_ail_update_bulk > xfs_trans_committed_bulk > xlog_cil_committed > xlog_state_do_callback > xlog_state_done_syncing > xlog_iodone > xfs_buf_iodone_work > process_one_work > worker_thread > kthread > kernel_thread_helper > The following patch fixes the problem for me. diff --git a/fs/xfs/linux-2.6/xfs_buf.c b/fs/xfs/linux-2.6/xfs_buf.c index 5e68099..2f34efd 100644 --- a/fs/xfs/linux-2.6/xfs_buf.c +++ b/fs/xfs/linux-2.6/xfs_buf.c @@ -1856,7 +1856,7 @@ xfs_buf_init(void) goto out; xfslogd_workqueue = alloc_workqueue("xfslogd", - WQ_MEM_RECLAIM | WQ_HIGHPRI, 1); + WQ_MEM_RECLAIM | WQ_UNBOUND, 1); if (!xfslogd_workqueue) goto out_free_buf_zone; -- Markus _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
