From: Krister Johansen <kjlx@templeofstupid.com>
To: Ali Saidi <alisaidi@amazon.com>
Cc: catalin.marinas@arm.com, james.morse@arm.com,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, maz@kernel.org, me@davidreaver.com,
oliver.upton@linux.dev, suzuki.poulose@arm.com, will@kernel.org,
yuzenghui@huawei.com
Subject: Re: [PATCH] KVM: arm64: Limit stage2_apply_range() batch size to smallest block
Date: Thu, 4 Apr 2024 14:41:56 -0700 [thread overview]
Message-ID: <20240404214156.GF2178@templeofstupid.com> (raw)
In-Reply-To: <20240404212742.11248-1-alisaidi@amazon.com>
On Thu, Apr 04, 2024 at 09:27:42PM +0000, Ali Saidi wrote:
> > Just a quick followup that I did test Will's patches and didn't find
> > that it changed the performance of the workload that I'd been testing.
> > IOW, I wasn't able to discern a network performance difference between
> > the baseline and those changes.
>
> That is a bit unexpected that the performance wasn't worse with the patch Will
> sent because it should have disabled the range invalidates since they these
> invalidates will be getting rid of blocks? Which Graviton were you testing
> this on?
Sorry I didn't mention it earlier. This was on a Graviton 4 with
FEAT_TLBIRANGE. Due to the placement of the test machine and the client
the max single flow rate was 5Gbps, and with both the baseline and
Will's patches I wasn't able to discern any slowdown there, at least in
terms of impact to the adjacent networking traffic. I saw an approx 1%
slowdown with multiple flows at 10Gbps, but didn't have a baseline for
that test case so was hesitant to offer it as conclusive. I should be
clear that I _wasn't_ measuring the the teardown times in this test
-- just how the teardown itself impacted the networking performance.
-K
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Krister Johansen <kjlx@templeofstupid.com>
To: Ali Saidi <alisaidi@amazon.com>
Cc: catalin.marinas@arm.com, james.morse@arm.com,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, maz@kernel.org, me@davidreaver.com,
oliver.upton@linux.dev, suzuki.poulose@arm.com, will@kernel.org,
yuzenghui@huawei.com
Subject: Re: [PATCH] KVM: arm64: Limit stage2_apply_range() batch size to smallest block
Date: Thu, 4 Apr 2024 14:41:56 -0700 [thread overview]
Message-ID: <20240404214156.GF2178@templeofstupid.com> (raw)
In-Reply-To: <20240404212742.11248-1-alisaidi@amazon.com>
On Thu, Apr 04, 2024 at 09:27:42PM +0000, Ali Saidi wrote:
> > Just a quick followup that I did test Will's patches and didn't find
> > that it changed the performance of the workload that I'd been testing.
> > IOW, I wasn't able to discern a network performance difference between
> > the baseline and those changes.
>
> That is a bit unexpected that the performance wasn't worse with the patch Will
> sent because it should have disabled the range invalidates since they these
> invalidates will be getting rid of blocks? Which Graviton were you testing
> this on?
Sorry I didn't mention it earlier. This was on a Graviton 4 with
FEAT_TLBIRANGE. Due to the placement of the test machine and the client
the max single flow rate was 5Gbps, and with both the baseline and
Will's patches I wasn't able to discern any slowdown there, at least in
terms of impact to the adjacent networking traffic. I saw an approx 1%
slowdown with multiple flows at 10Gbps, but didn't have a baseline for
that test case so was hesitant to offer it as conclusive. I should be
clear that I _wasn't_ measuring the the teardown times in this test
-- just how the teardown itself impacted the networking performance.
-K
next prev parent reply other threads:[~2024-04-04 21:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-28 19:04 [RFC] KVM: arm64: improving IO performance during unmap? Krister Johansen
2024-03-28 19:04 ` Krister Johansen
2024-03-28 19:05 ` [PATCH] KVM: arm64: Limit stage2_apply_range() batch size to smallest block Krister Johansen
2024-03-28 19:05 ` Krister Johansen
2024-03-29 13:48 ` Oliver Upton
2024-03-29 13:48 ` Oliver Upton
2024-03-29 19:15 ` Krister Johansen
2024-03-29 19:15 ` Krister Johansen
2024-03-30 10:17 ` Marc Zyngier
2024-03-30 10:17 ` Marc Zyngier
2024-04-02 17:00 ` Krister Johansen
2024-04-02 17:00 ` Krister Johansen
2024-04-04 4:40 ` Krister Johansen
2024-04-04 4:40 ` Krister Johansen
2024-04-04 21:27 ` Ali Saidi
2024-04-04 21:27 ` Ali Saidi
2024-04-04 21:41 ` Krister Johansen [this message]
2024-04-04 21:41 ` Krister Johansen
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=20240404214156.GF2178@templeofstupid.com \
--to=kjlx@templeofstupid.com \
--cc=alisaidi@amazon.com \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=me@davidreaver.com \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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.