Hey, Christoph.
On Thu, Mar 21, 2013 at 09:08:19AM -0400, Christoph Hellwig wrote:
> > > Hmm... I guess, then, what we can do is adding a worker description
> > > which is printed out with task dump. ie. A work function can call
> > > work_set_desc(fmt, arg). It won't be expensive and can
On Thu, Mar 21, 2013 at 12:32:52PM +0100, Jan Kara wrote:
> On Wed 20-03-13 22:07:18, Tejun Heo wrote:
> > Hello, Dave.
> >
> > On Thu, Mar 21, 2013 at 12:57:21PM +1100, Dave Chinner wrote:
> > > When you have a system that has 50+ active filesystems (pretty
> > > common in the distributed
On Wed 20-03-13 22:07:18, Tejun Heo wrote:
> Hello, Dave.
>
> On Thu, Mar 21, 2013 at 12:57:21PM +1100, Dave Chinner wrote:
> > 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
On Wed 20-03-13 22:07:18, Tejun Heo wrote:
Hello, Dave.
On Thu, Mar 21, 2013 at 12:57:21PM +1100, Dave Chinner wrote:
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
On Thu, Mar 21, 2013 at 12:32:52PM +0100, Jan Kara wrote:
On Wed 20-03-13 22:07:18, Tejun Heo wrote:
Hello, Dave.
On Thu, Mar 21, 2013 at 12:57:21PM +1100, Dave Chinner wrote:
When you have a system that has 50+ active filesystems (pretty
common in the distributed storage
Hey, Christoph.
On Thu, Mar 21, 2013 at 09:08:19AM -0400, Christoph Hellwig wrote:
Hmm... I guess, then, what we can do is adding a worker description
which is printed out with task dump. ie. A work function can call
work_set_desc(fmt, arg). It won't be expensive and can be
Hello, Dave.
On Thu, Mar 21, 2013 at 12:57:21PM +1100, Dave Chinner wrote:
> 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
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 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...
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
Hello, Dave.
On Thu, Mar 21, 2013 at 12:57:21PM +1100, Dave Chinner wrote:
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
Hello, Jan.
On Tue, Mar 19, 2013 at 8:46 AM, Jan Kara 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
On Mon 18-03-13 15:35:26, Tejun Heo wrote:
> On Mon, Mar 18, 2013 at 11:32:44PM +0100, Jan Kara wrote:
> > I realized there may be one issue - so far we have a clear identification
> > which thread works for which bdi in the thread name (flush-x:y naming).
> > That was useful when debugging
On Mon 18-03-13 15:35:26, Tejun Heo wrote:
On Mon, Mar 18, 2013 at 11:32:44PM +0100, Jan Kara wrote:
I realized there may be one issue - so far we have a clear identification
which thread works for which bdi in the thread name (flush-x:y naming).
That was useful when debugging things. Now
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
Hello, Jan.
On Mon, Mar 18, 2013 at 11:32:44PM +0100, Jan Kara wrote:
> I realized there may be one issue - so far we have a clear identification
> which thread works for which bdi in the thread name (flush-x:y naming).
> That was useful when debugging things. Now with your worker pool this is
On Tue 12-03-13 16:05:10, Jan Kara wrote:
> On Thu 07-03-13 13:44:08, Tejun Heo wrote:
> > Writeback implements its own worker pool - each bdi can be associated
> > with a worker thread which is created and destroyed dynamically. The
> > worker thread for the default bdi is always present and
On Tue 12-03-13 16:05:10, Jan Kara wrote:
On Thu 07-03-13 13:44:08, Tejun Heo wrote:
Writeback implements its own worker pool - each bdi can be associated
with a worker thread which is created and destroyed dynamically. The
worker thread for the default bdi is always present and serves as
Hello, Jan.
On Mon, Mar 18, 2013 at 11:32:44PM +0100, Jan Kara wrote:
I realized there may be one issue - so far we have a clear identification
which thread works for which bdi in the thread name (flush-x:y naming).
That was useful when debugging things. Now with your worker pool this is
On Thu 07-03-13 13:44:08, Tejun Heo wrote:
> Writeback implements its own worker pool - each bdi can be associated
> with a worker thread which is created and destroyed dynamically. The
> worker thread for the default bdi is always present and serves as the
> "forker" thread which forks off
On Thu 07-03-13 13:44:08, Tejun Heo wrote:
Writeback implements its own worker pool - each bdi can be associated
with a worker thread which is created and destroyed dynamically. The
worker thread for the default bdi is always present and serves as the
forker thread which forks off worker
Writeback implements its own worker pool - each bdi can be associated
with a worker thread which is created and destroyed dynamically. The
worker thread for the default bdi is always present and serves as the
"forker" thread which forks off worker threads for other bdis.
there's no reason for
Writeback implements its own worker pool - each bdi can be associated
with a worker thread which is created and destroyed dynamically. The
worker thread for the default bdi is always present and serves as the
forker thread which forks off worker threads for other bdis.
there's no reason for
22 matches
Mail list logo
