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
--
Markus