linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Darrick J. Wong" <djwong@kernel.org>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 4/3] xfs: set WQ_SYSFS on all workqueues in debug mode
Date: Thu, 28 Jan 2021 10:29:42 +1100	[thread overview]
Message-ID: <20210127232942.GM4662@dread.disaster.area> (raw)
In-Reply-To: <20210127170306.GC1730140@infradead.org>

On Wed, Jan 27, 2021 at 05:03:06PM +0000, Christoph Hellwig wrote:
> On Mon, Jan 25, 2021 at 09:06:19PM -0800, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > When CONFIG_XFS_DEBUG=y, set WQ_SYSFS on all workqueues that we create
> > so that we (developers) have a means to monitor cpu affinity and whatnot
> > for background workers.  In the next patchset we'll expose knobs for
> > some of the workqueues publicly and document it, but not now.
> 
> I don't really think this is a very good idea.  If we want something like
> this it should be kernel-wide and coordinated with the workqueue 
> maintainer, but I'm a little doubtful about the use case.

I don't think it is particular useful kernel wide. If it was, the
maintainer wouldn't have introduced a per-workqueue flag for this
functionality.

The reality is that very few workqueues in the system can expand out
into running thousands of kworker threads like the XFS workqueues
often do. And, really, there's nothing useful a typical user can do
at this point with the workqueue knobs to "tune" the behaviour - the
visibility/control the workqueue sysfs knobs provide at this point
is really only useful to XFS developers running tests in controlled
conditions...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

      reply	other threads:[~2021-01-27 23:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-23 18:53 [PATCHSET 0/3] xfs: speed up parallel workqueues Darrick J. Wong
2021-01-23 18:53 ` [PATCH 1/3] xfs: increase the default parallelism levels of pwork clients Darrick J. Wong
2021-01-24  9:57   ` Christoph Hellwig
2021-01-25 23:07     ` Darrick J. Wong
2021-01-26  5:04   ` [PATCH v2.1 " Darrick J. Wong
2021-01-26 20:46     ` Dave Chinner
2021-01-26 23:32       ` Darrick J. Wong
2021-01-23 18:53 ` [PATCH 2/3] xfs: use unbounded workqueues for parallel work Darrick J. Wong
2021-01-24  9:51   ` Christoph Hellwig
2021-01-25 23:18     ` Darrick J. Wong
2021-01-23 18:53 ` [PATCH 3/3] xfs: set WQ_SYSFS on all workqueues Darrick J. Wong
2021-01-24  9:54   ` Christoph Hellwig
2021-01-25 23:30     ` Darrick J. Wong
2021-01-26  5:06   ` [PATCH 4/3] xfs: set WQ_SYSFS on all workqueues in debug mode Darrick J. Wong
2021-01-26 20:48     ` Dave Chinner
2021-01-27 17:03     ` Christoph Hellwig
2021-01-27 23:29       ` Dave Chinner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210127232942.GM4662@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).