From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: alternative:flush cache with unpatched code
Date: Wed, 6 Jun 2018 16:44:56 +0100 [thread overview]
Message-ID: <20180606154455.GH6631@arm.com> (raw)
In-Reply-To: <1528218506299.33619@nvidia.com>
On Tue, Jun 05, 2018 at 05:07:54PM +0000, Alexander Van Brunt wrote:
> > 1. Boot. This happens once, and we end up putting *all* secondary cores into
> > a tight loop anyway, so I don't see that the performance of
> > __flush_icache_all is relevant
>
> Native boot happens once. But, each VM that boots will slow down all of
> the other VM's on the system. A VM boot can happen thousands of times.
>
> I really don't want to cause the whole system to hiccup for a millisecond
> or more when there are only a few cache lines that need to be invalidated.
You know we already do this on boot, right? If it's a real issue, I'd argue
that it's the hypervisor's problem to solve.
Anyway, please can you back this up with some real numbers that show the
impact on a real use-case? It feels like we've quickly getting into
hypothetical territory here because you have a instinctive dislike for full
I-cache invalidation.
Will
next prev parent reply other threads:[~2018-06-06 15:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-29 18:11 [PATCH] arm64: alternative:flush cache with unpatched code Rohit Khanna
2018-05-30 9:00 ` Will Deacon
2018-05-31 17:45 ` Rohit Khanna
2018-06-04 9:16 ` Will Deacon
2018-06-04 19:34 ` Alexander Van Brunt
2018-06-05 16:55 ` Will Deacon
2018-06-05 17:07 ` Alexander Van Brunt
2018-06-06 15:44 ` Will Deacon [this message]
2018-06-06 16:16 ` Alexander Van Brunt
-- strict thread matches above, loose matches on Subject: below --
2018-06-02 0:39 Rohit Khanna
2018-05-31 20:37 Rohit Khanna
2018-06-01 9:03 ` Mark Rutland
2018-06-01 19:52 ` Rohit Khanna
2018-06-01 21:43 ` Rohit Khanna
2018-06-04 9:01 ` Mark Rutland
2018-05-22 18:07 Rohit Khanna
2018-05-23 9:06 ` Will Deacon
2018-05-22 1:27 Rohit Khanna
2018-05-22 15:09 ` Suzuki K Poulose
2018-05-22 18:08 ` Rohit Khanna
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=20180606154455.GH6631@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.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 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.