On Sun, Jan 24, 2021 at 09:54:54AM +0000, Christoph Hellwig wrote:

quoted

 	log->l_ioend_workqueue = alloc_workqueue("xfs-log/%s",
-			WQ_MEM_RECLAIM | WQ_FREEZABLE | WQ_HIGHPRI, 0,
-			mp->m_super->s_id);
+			WQ_SYSFS | WQ_MEM_RECLAIM | WQ_FREEZABLE | WQ_HIGHPRI,
+			0, mp->m_super->s_id);

This is just used for log I/O completions which are effectlively single
thread.  I don't see any reason to adjust the parameters here.

quoted

 	if (!log->l_ioend_workqueue)
 		goto out_free_iclog;
 

diff --git a/fs/xfs/xfs_mru_cache.c b/fs/xfs/xfs_mru_cache.c
index a06661dac5be..b6dab34e361d 100644
--- a/fs/xfs/xfs_mru_cache.c
+++ b/fs/xfs/xfs_mru_cache.c

@@ -294,7 +294,7 @@ int
 xfs_mru_cache_init(void)
 {
 	xfs_mru_reap_wq = alloc_workqueue("xfs_mru_cache",
-				WQ_MEM_RECLAIM|WQ_FREEZABLE, 1);
+				WQ_SYSFS | WQ_MEM_RECLAIM | WQ_FREEZABLE, 1);
 	if (!xfs_mru_reap_wq)
 		return -ENOMEM;

This one also hasn't ever been something we tune, so I don't think there
is a good case for enabling WQ_SYSFS.

Yeah, the only ones I want to push for (and hence document) are
quotacheck, background blockgc, and (in 5.13) background inode
inactivation.

I've stopped here.  I think we should have a good use case for making
workqueues show up in sysfs based on that we:

 a) have resons to adjust them ever
 b) actually having them easily discoverable and documented for adminds
    to tune

TBH I think the only workqueues we really ought to expose publicly are
the unbound ones, since they represent kernel threads that can log
transactions, and hence are known to have a performance impact that
sysadmins could tune reasonably.

Dave suggests exposing them all on a debug kernel, of course. :)

--D