From: Yan Zhao <yan.y.zhao@intel.com>
To: kraxel@redhat.com, maarten.lankhorst@linux.intel.com,
mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com,
daniel@ffwll.ch, virtualization@lists.linux.dev,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Cc: pbonzini@redhat.com, seanjc@google.com, kvm@vger.kernel.org,
Yan Zhao <yan.y.zhao@intel.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Kevin Tian <kevin.tian@intel.com>
Subject: [PATCH v2] drm/bochs: use devm_ioremap_wc() to map framebuffer
Date: Mon, 9 Sep 2024 21:16:43 +0800 [thread overview]
Message-ID: <20240909131643.28915-1-yan.y.zhao@intel.com> (raw)
Opt for devm_ioremap_wc() over devm_ioremap() when mapping the framebuffer.
Using devm_ioremap() results in the VA being mapped with PAT=UC-, which
considerably slows down drm_fb_memcpy(). In contrast, devm_ioremap_wc()
maps the VA with PAT set to WC, leading to better performance on platforms
where access to UC memory is much slower than WC memory.
Here's the performance data measured in a guest on the physical machine
"Sapphire Rapids XCC".
With host KVM honors guest PAT memory types, the effective memory type
for this framebuffer range is
- WC when devm_ioremap_wc() is used
- UC- when devm_ioremap() is used.
The data presented is an average from 10 execution runs.
Cycles: Avg cycles of executed bochs_primary_plane_helper_atomic_update()
from VM boot to GDM show up
Cnt: Avg cnt of executed bochs_primary_plane_helper_atomic_update()
from VM boot to GDM show up
T: Avg time of each bochs_primary_plane_helper_atomic_update().
-------------------------------------------------
| | devm_ioremap() | devm_ioremap_wc() |
|------------|----------------|-------------------|
| Cycles | 211.545M | 0.157M |
|------------|----------------|-------------------|
| Cnt | 142 | 1917 |
|------------|----------------|-------------------|
| T | 0.1748s | 0.0004s |
-------------------------------------------------
Note:
Following the rebase to [3], the previously reported GDM failure on the
VGA device [1] can no longer be reproduced, thanks to the memory management
improvements made in [2]. Despite this, I have proceeded to submit this
patch because of the noticeable performance improvements it provides.
Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Closes: https://lore.kernel.org/all/87jzfutmfc.fsf@redhat.com/#t
Cc: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
Link: https://lore.kernel.org/all/87jzfutmfc.fsf@redhat.com/#t [1]
Link: https://patchwork.freedesktop.org/series/138086 [2]
Link: https://gitlab.freedesktop.org/drm/misc/kernel/-/tree/drm-misc-next [3]
---
v2:
- Rebased to the latest drm-misc-next branch. [2]
- Updated patch log to match the base code.
v1: https://lore.kernel.org/all/20240909051529.26776-1-yan.y.zhao@intel.com
---
drivers/gpu/drm/tiny/bochs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index 69c5f65e9853..9055b1dd66df 100644
--- a/drivers/gpu/drm/tiny/bochs.c
+++ b/drivers/gpu/drm/tiny/bochs.c
@@ -268,7 +268,7 @@ static int bochs_hw_init(struct bochs_device *bochs)
if (!devm_request_mem_region(&pdev->dev, addr, size, "bochs-drm"))
DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
- bochs->fb_map = devm_ioremap(&pdev->dev, addr, size);
+ bochs->fb_map = devm_ioremap_wc(&pdev->dev, addr, size);
if (bochs->fb_map == NULL) {
DRM_ERROR("Cannot map framebuffer\n");
return -ENOMEM;
--
2.43.2
next reply other threads:[~2024-09-09 13:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-09 13:16 Yan Zhao [this message]
2024-09-10 7:24 ` Thomas Zimmermann
2024-09-10 8:05 ` Yan Zhao
2024-09-11 6:29 ` Thomas Zimmermann
2024-09-10 12:49 ` Vitaly Kuznetsov
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=20240909131643.28915-1-yan.y.zhao@intel.com \
--to=yan.y.zhao@intel.com \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=kevin.tian@intel.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tzimmermann@suse.de \
--cc=virtualization@lists.linux.dev \
--cc=vkuznets@redhat.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
all inboxes | Powered by JetHome®