Hello, Eric.
On Fri, Jan 09, 2015 at 02:36:28PM -0600, Eric Sandeen wrote:
> And the xfsalloc / btree split worker is not on any active task.
> Digging further, it's on a queue, but not started.
>
> The work queue which contains it is this:
>
> crash> list -H 0xc000000001cd7b18 -o work_struct.entry -s work_struct
> c0000006182ceed8
> struct work_struct {
...
> func = 0xd000000005c0b570 <xfs_end_io>
> }
> c0000006182c31f0
> struct work_struct {
...
> func = 0xd000000005c0b570 <xfs_end_io>
> }
> c0000006182c0748
> struct work_struct {
...
> func = 0xd000000005c0b570 <xfs_end_io>
> }
> c00000003ad030a0
> struct work_struct {
...
> func = 0xd000000005c58ef0 <xfs_btree_split_worker>
> }
>
> ...
>
> so that's our stuck split worker, behind xfs_end_io's.
As long as the split worker is queued on a separate workqueue, it's
not really stuck behind xfs_end_io's. If the global pool that the
work item is queued on can't make forward progress due to memory
pressure, the rescuer will be summoned and it will pick out that work
item and execute it.
The only reasons that work item would stay there are
* The rescuer is already executing something else from that workqueue
and that one is stuck.
* The worker pool is still considered to be making forward progress -
there's a worker which isn't blocked and can burn CPU cycles.
ie. if you have a busy spinning work item on the per-cpu workqueue,
it can stall progress.
...
> and xfs_iomap_write_direct() takes the ilock exclusively.
>
> xfs_ilock(ip, XFS_ILOCK_EXCL);
>
> before calling xfs_bmapi_write(), so it must be the holder. Until
> this work item runs, everything else working on this inode is stuck,
> but it's not getting run, behind other items waiting for the lock it
> holds.
Again, if xfs is using workqueue correctly, that work item shouldn't
get stuck at all. What other workqueues are doing is irrelevant.
Thanks.
--
tejun
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
