On Tue, Mar 19, 2013 at 10:28:24AM -0700, Tejun Heo wrote: > Hello, Jan. > > On Tue, Mar 19, 2013 at 8:46 AM, Jan Kara <j...@suse.cz> wrote: > > Well, but what you often get is just output of sysrq-w, or sysrq-t, or > > splat from scheduler about stuck task. You often don't have the comfort of > > tracing... Can't we somehow change 'comm' of the task when it starts > > processing work of some bdi? > > You sure can but I'd prefer not to do that. If you wanna do it > properly, you have to grab task lock every time a work item starts > execution. I'm not sure how beneficial having the block device > identifier would be. Backtrace would be there the same. Is identifying > the block device that important?
When you have a system that has 50+ active filesystems (pretty common in the distributed storage environments were every disk has it's own filesystem), knowing which filesystem(s) are getting stuck in writeback from the sysrq-w or hangcheck output is pretty damn important.... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
