Messages in this thread | | | Date | Thu, 21 Mar 2013 12:57:21 +1100 | From | Dave Chinner <> | Subject | Re: [PATCH 3/4] writeback: replace custom worker pool implementation with unbound workqueue |
| |
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 <jack@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 david@fromorbit.com
| |