All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Gary R Hook <ghook-5C7GfCeVMHo@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] iommu/amd - Optimize PPR log handling
Date: Wed, 30 May 2018 06:52:04 +0200	[thread overview]
Message-ID: <20180530045203.GO18595@8bytes.org> (raw)
In-Reply-To: <223930b9-3df9-813a-6676-68072e4e1bb6-5C7GfCeVMHo@public.gmane.org>

On Tue, May 29, 2018 at 12:28:54PM -0500, Gary R Hook wrote:
> No, no numbers. We're still working out how best to test this, and
> suggestions/strategies are welcome.

Maybe run a simple kernel on the CPU that does a memcpy on a larger
portion of mmapped (but yet unmapped) process address space and measure
the time it takes for the kernel to run. The page-fault path in the
iommu-driver is only a small part of the involved code here, but maybe
you already see a difference. Doing a u-benchmark only for that code is
probably a bit more challenging.

> The change is modeled after the function iommu_poll_events(), which is much
> cleaner. The GA log handling should be changed, as well (there are
> superfluous writes in the loop), but I figured, "one thing at a time". This
> is admittedly a minor optimization, but discussions with Tom Lendacky have
> led us down this path.
> 
> Your feedback is appreciated.

Yeah, the patch looks good to me from my first review. But since I can't
test that code myself I was wondering if you did any tests and can share
something with me to run my own tests :)



	Joerg

WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Gary R Hook <ghook@amd.com>
Cc: Gary R Hook <gary.hook@amd.com>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu/amd - Optimize PPR log handling
Date: Wed, 30 May 2018 06:52:04 +0200	[thread overview]
Message-ID: <20180530045203.GO18595@8bytes.org> (raw)
In-Reply-To: <223930b9-3df9-813a-6676-68072e4e1bb6@amd.com>

On Tue, May 29, 2018 at 12:28:54PM -0500, Gary R Hook wrote:
> No, no numbers. We're still working out how best to test this, and
> suggestions/strategies are welcome.

Maybe run a simple kernel on the CPU that does a memcpy on a larger
portion of mmapped (but yet unmapped) process address space and measure
the time it takes for the kernel to run. The page-fault path in the
iommu-driver is only a small part of the involved code here, but maybe
you already see a difference. Doing a u-benchmark only for that code is
probably a bit more challenging.

> The change is modeled after the function iommu_poll_events(), which is much
> cleaner. The GA log handling should be changed, as well (there are
> superfluous writes in the loop), but I figured, "one thing at a time". This
> is admittedly a minor optimization, but discussions with Tom Lendacky have
> led us down this path.
> 
> Your feedback is appreciated.

Yeah, the patch looks good to me from my first review. But since I can't
test that code myself I was wondering if you did any tests and can share
something with me to run my own tests :)



	Joerg

  parent reply	other threads:[~2018-05-30  4:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-18 21:51 [PATCH] iommu/amd - Optimize PPR log handling Gary R Hook
2018-05-18 21:51 ` Gary R Hook
     [not found] ` <152668031618.108078.8188026193559324640.stgit-ztPFugr8rmfEhiLOc2DLklaTQe2KTcn/@public.gmane.org>
2018-05-29 14:54   ` Joerg Roedel
2018-05-29 14:54     ` Joerg Roedel
     [not found]     ` <20180529145405.GN18595-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2018-05-29 17:28       ` Gary R Hook
2018-05-29 17:28         ` Gary R Hook
     [not found]         ` <223930b9-3df9-813a-6676-68072e4e1bb6-5C7GfCeVMHo@public.gmane.org>
2018-05-30  4:52           ` Joerg Roedel [this message]
2018-05-30  4:52             ` Joerg Roedel

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=20180530045203.GO18595@8bytes.org \
    --to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
    --cc=ghook-5C7GfCeVMHo@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.