From: Tejun Heo <tj@kernel.org>
To: Sandeep Dhavale <dhavale@google.com>
Cc: Nathan Huckleberry <nhuck@google.com>,
Daeho Jeong <daehojeong@google.com>,
Eric Biggers <ebiggers@kernel.org>,
Sami Tolvanen <samitolvanen@google.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] workqueue: Add WQ_SCHED_FIFO
Date: Wed, 18 Jan 2023 08:25:57 -1000 [thread overview]
Message-ID: <Y8g5tR8tup8LHbb7@slm.duckdns.org> (raw)
In-Reply-To: <CAB=BE-Q9jtJnqPwGzSTQ6-soZ9STvqAebeONy=Eyo08H+eg-rQ@mail.gmail.com>
On Wed, Jan 18, 2023 at 10:22:32AM -0800, Sandeep Dhavale wrote:
> If with the kernel config option, every WQ_HIGHPRI is elevated to
> sched_fifo_low, wouldn't that be kind of defeating the purpose? Having
> another class for even more urgent work is better in my opinion.
I mean, everybody thinks their work items are the most important. Even with
explicit FIFO, you're still gonna have similar problems as people crowd that
flag. If this is a concern, please benchmark with realistic scenarios and
consider other options (e.g. maybe that problematic workqueue doesn't need
to be HIGHPRI or should be split somehow). Right now, I don't think there
are enough justifications for adding another level.
Thanks.
--
tejun
next prev parent reply other threads:[~2023-01-18 18:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-13 21:07 [PATCH] workqueue: Add WQ_SCHED_FIFO Nathan Huckleberry
2023-01-13 21:11 ` Tejun Heo
2023-01-14 21:00 ` Nathan Huckleberry
2023-01-18 17:51 ` Tejun Heo
2023-01-18 18:22 ` Sandeep Dhavale
2023-01-18 18:25 ` Tejun Heo [this message]
2023-01-18 22:04 ` Nathan Huckleberry
2023-01-19 2:01 ` Nathan Huckleberry
2023-01-19 2:28 ` Tejun Heo
2023-01-27 19:25 ` Nathan Huckleberry
2023-01-14 2:19 ` Gao Xiang
2023-01-14 2:19 ` Gao Xiang
2023-01-14 21:00 ` Nathan Huckleberry via Linux-erofs
2023-01-14 21:00 ` Nathan Huckleberry
2023-01-15 1:51 ` Hillf Danton
2023-01-19 2:41 ` Sandeep Dhavale via Linux-erofs
2023-01-19 2:41 ` Sandeep Dhavale
2023-01-19 4:31 ` Gao Xiang
2023-01-19 4:31 ` Gao Xiang
2023-02-12 13:56 ` kernel test robot
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=Y8g5tR8tup8LHbb7@slm.duckdns.org \
--to=tj@kernel.org \
--cc=corbet@lwn.net \
--cc=daehojeong@google.com \
--cc=dhavale@google.com \
--cc=ebiggers@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nhuck@google.com \
--cc=samitolvanen@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.