public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: prabin ca <prabinca4u@gmail.com>
Cc: edk2-devel@lists.01.org
Subject: Re: PerformancePkg on multiple platform
Date: Fri, 3 Aug 2018 20:17:04 +0200	[thread overview]
Message-ID: <1deaed58-5098-aa30-b401-f415a034957d@redhat.com> (raw)
In-Reply-To: <8E875131-258C-4F21-B104-EB36CE970701@gmail.com>

Hi Prabin,

On 08/03/18 09:29, prabin ca wrote:
> Hi Team,
> 
> I’m new to uefi and edk. Currently I’m trying to get performance of my dxe driver using PerformancePkg of EDK source code.
> 
> I’m using perf_start and perf_end T respected check points, it’s hot build and tested well in 2/3 platform. It’s giving proper response.
> 
> But when I’m Checking with multiple platform, in some of platforms it’s not working and got hang in uefi she’ll itself.
> 
> Please help me to resolve asap, it will be really helpful.

I can only give you some hints, because thus far I have also failed to
figure out how performance measurements should be enabled for a platform
from scratch.

Earlier I thought that an interested platform should include modules
from PerformancePkg. I got some good results that way; however:

- it wouldn't work for AARCH64, and so I filed
  <https://bugzilla.tianocore.org/show_bug.cgi?id=679>

- ultimately PerformancePkg was removed in commit 922c1e94e4bb
  completely. (And for that reason I now closed TianoCore#679 as
  WONTFIX.)

Commit 922c1e94e4bb doesn't really give pointers for enabling
performance measurements in a platform -- it refers the user to the DP
shell command instead of the standalone DP application, but that's only
for displaying the stats, not for recording them.

One document where I found information is the Intel whitepaper

  A Tour Beyond BIOS
  Implementing Profiling in with EDK II

(just google it). "Part III – Performance Profile" is relevant.

The first section of that talks about enabling ACPI FPDT (ACPI Firmware
Performance Data Table) support in edk2, for exposing firmware
performance data to the OS. Again, that's not about *recording* the stats.

The second section of the same chapter seems to describe how stats can
be recorded however. AIUI, the DXE Core can provide the PERFORMANCE[_EX]
protocols, if the DxeCorePerformanceLib instance is linked into it by
the platform DSC file. In turn DXE modules can send measurements to the
protocol via the PerformanceLib APIs / DxePerformanceLib instance.

In fact, the relevant library INF files have good documentation, we just
have to know what to look at.

Recording stats in the PEI phase, via HOBs:
- MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf

Recording stats in the DXE phase (protocol provider and consumer):
- MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.inf
- MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf

Recording stats in SMM (protocol provider and consumer):
- MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.inf
- MdeModulePkg/Library/SmmPerformanceLib/SmmPerformanceLib.inf

Fetching the collected stats (for display or otherwise):
- MdeModulePkg/Library/DxeSmmPerformanceLib/DxeSmmPerformanceLib.inf

"Do nothing" library instance for all module types:
- MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf


Now obviously this doesn't explain why it works for you on some
platforms and why it doesn't on others. You haven't shared much
information about the platforms in question. I can make one guess: if
the performance protocol provided by the platform's DXE Core
(DxeCorePerformanceLib) is incompatible with the DxePerformanceLib
instance that is linked into your DXE driver, then communication between
them will likely fail.

To my understanding, the performance protocol is not standard (PI or
UEFI), so it's likely best if you build your DXE driver together with
the DXE Core, on all platforms that you want to check. It's probably
unsafe to link a DXE driver against DxePerformanceLib (rather than
BasePerformanceLibNull) and run it on a random platform.

Hopefully this helps a little.
Laszlo


  reply	other threads:[~2018-08-03 18:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-03  7:29 PerformancePkg on multiple platform prabin ca
2018-08-03 18:17 ` Laszlo Ersek [this message]
2018-08-03 18:38   ` PerformancePkg on multiple platform - Andrew Fish
2018-08-04  5:19     ` prabin ca
2018-08-04 10:11       ` Bi, Dandan
2018-08-04 10:29         ` prabin ca
2018-08-06 14:51         ` prabin ca
2018-08-04  5:17   ` PerformancePkg on multiple platform prabin ca

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-list 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=1deaed58-5098-aa30-b401-f415a034957d@redhat.com \
    --to=devel@edk2.groups.io \
    /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