From: David Laight <David.Laight@ACULAB.COM>
To: 'Sebastian Andrzej Siewior' <bigeasy@linutronix.de>,
Davidlohr Bueso <dave@stgolabs.net>
Cc: Tyrel Datwyler <tyreld@linux.ibm.com>,
"ejb@linux.ibm.com" <ejb@linux.ibm.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: RE: [PATCH 09/10] scsi/ibmvscsi: Replace srp tasklet with work
Date: Thu, 9 Jun 2022 15:46:04 +0000 [thread overview]
Message-ID: <7faa88aaf7554545a60561d73597dc4f@AcuMS.aculab.com> (raw)
In-Reply-To: <YqILmd/WnNT/zYrf@linutronix.de>
From: Sebastian Andrzej Siewior
> Sent: 09 June 2022 16:03
>
> On 2022-05-30 16:15:11 [-0700], Davidlohr Bueso wrote:
> > Tasklets have long been deprecated as being too heavy on the system
> > by running in irq context - and this is not a performance critical
> > path. If a higher priority process wants to run, it must wait for
> > the tasklet to finish before doing so.
> >
> > Process srps asynchronously in process context in a dedicated
> > single threaded workqueue.
>
> I would suggest threaded interrupts instead. The pattern here is the
> same as in the previous driver except here is less locking.
How long do these actions runs for, and what is waiting for
them to finish?
These changes seem to drop the priority from above that of the
highest priority RT process down to that of a default priority
user process.
There is no real guarantee that the latter will run 'any time soon'.
Consider some workloads I'm setting up where most of the cpu are
likely to spend 90%+ of the time running processes under the RT
scheduler that are processing audio.
It is quite likely that a non-RT thread (especially one bound
to a specific cpu) won't run for several milliseconds.
(We have to go through 'hoops' to avoid dropping ethernet frames.)
I'd have thought that some of these kernel threads really
need to run at a 'middling' RT priority.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2022-06-09 15:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220530231512.9729-1-dave@stgolabs.net>
2022-05-30 23:15 ` [PATCH 06/10] scsi/ibmvscsi_tgt: Replace work tasklet with threaded irq Davidlohr Bueso
2022-06-03 11:05 ` Sebastian Andrzej Siewior
2022-05-30 23:15 ` [PATCH 08/10] scsi/ibmvfc: Replace tasklet with work Davidlohr Bueso
2022-06-09 12:30 ` Sebastian Andrzej Siewior
2022-06-28 15:18 ` Davidlohr Bueso
2022-05-30 23:15 ` [PATCH 09/10] scsi/ibmvscsi: Replace srp " Davidlohr Bueso
2022-06-09 15:02 ` Sebastian Andrzej Siewior
2022-06-09 15:46 ` David Laight [this message]
2022-06-14 13:25 ` 'Sebastian Andrzej Siewior'
2022-06-14 13:34 ` David Laight
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=7faa88aaf7554545a60561d73597dc4f@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=bigeasy@linutronix.de \
--cc=dave@stgolabs.net \
--cc=ejb@linux.ibm.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=martin.petersen@oracle.com \
--cc=tglx@linutronix.de \
--cc=tyreld@linux.ibm.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 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).