From: Douglas Anderson <dianders@chromium.org>
To: Mark Brown <broonie@kernel.org>,
Benson Leung <bleung@chromium.org>,
Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: linux-rockchip@lists.infradead.org, drinkcat@chromium.org,
Guenter Roeck <groeck@chromium.org>,
briannorris@chromium.org, mka@chromium.org,
Douglas Anderson <dianders@chromium.org>,
linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org
Subject: [PATCH v2 0/3] spi: A better solution for cros_ec_spi reliability
Date: Mon, 13 May 2019 13:18:22 -0700 [thread overview]
Message-ID: <20190513201825.166969-1-dianders@chromium.org> (raw)
This series is a much better solution for getting the Chrome OS EC to
talk reliably and replaces commit 37a186225a0c ("platform/chrome:
cros_ec_spi: Transfer messages at high priority").
Specifically note that even though the above commit made things
better, we still saw some failures.
The majority of these failures were because we were competing for time
with dm-crypt which also scheduled work on HIGHPRI workqueues. While
we can consider reverting the change that made dm-crypt run its work
at HIGHPRI, the argument in commit a1b89132dc4f ("dm crypt: use
WQ_HIGHPRI for the IO and crypt workqueues") is somewhat compelling.
It does make sense for IO to be scheduled at a priority that's higher
than the default user priority.
It turns out that we could also see problems because loop devices also
run at high priority. See the set_user_nice() in
loop_prepare_queue().
Looking in more detail, it can be seen that the high priority
workqueue isn't actually that high of a priority. It runs at MIN_NICE
which is _fairly_ high priority but still below all real time
priority. We can do better by using realtime priority. That makes
sense because cros_ec_spi actually needs to run quickly for
correctness. As I understand this is exactly what real time priority
is for. Note that there is a discussion going on about the dm-crypt
priority [1].
We also had other problems with the previous patch because sometimes
we'd end up on the SPI pumping thread and had our priority downgraded.
Both the competition with other high priority things and the priority
downgrading are fixed by this new series.
After this series I can run the following test on Chrome OS (which
mounts /var as stateful encrypted) with no errors:
dd if=/dev/zero of=/var/log/foo.txt bs=4M count=512&
while true; do
ectool version > /dev/null;
done
Special thanks to Guenter Roeck for pointing out the "realtime"
feature of the SPI framework so I didn't re-invent the wheel. I have
no idea how I missed it. :-/
Also note: if you want some history on investigation done here, feel
free to peruse the Chrome OS bug [2].
[1] https://lkml.kernel.org/r/CAD=FV=VOAjgdrvkK8YKPP-8zqwPpo39rA43JH2BCeYLB0UkgAQ@mail.gmail.com
[2] https://crbug.com/948742
Changes in v2:
- Now only force transfers to the thread for devices that want it.
- Squashed patch #1 and #2 together.
- Renamed variable to "force_rt_transfers".
Douglas Anderson (3):
spi: Allow SPI devices to force transfers on a realtime thread
platform/chrome: cros_ec_spi: Force transfers to realtime priority
Revert "platform/chrome: cros_ec_spi: Transfer messages at high
priority"
drivers/platform/chrome/cros_ec_spi.c | 81 +++------------------------
drivers/spi/spi.c | 49 +++++++++++++---
include/linux/spi/spi.h | 5 ++
3 files changed, 52 insertions(+), 83 deletions(-)
--
2.21.0.1020.gf2820cf01a-goog
next reply other threads:[~2019-05-13 20:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-13 20:18 Douglas Anderson [this message]
2019-05-13 20:18 ` [PATCH v2 1/3] spi: Allow SPI devices to force transfers on a realtime thread Douglas Anderson
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=20190513201825.166969-1-dianders@chromium.org \
--to=dianders@chromium.org \
--cc=bleung@chromium.org \
--cc=briannorris@chromium.org \
--cc=broonie@kernel.org \
--cc=drinkcat@chromium.org \
--cc=enric.balletbo@collabora.com \
--cc=groeck@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=mka@chromium.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).