Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a config to MIBC format #71359

Merged
merged 10 commits into from
Jul 1, 2022
Merged

Add a config to MIBC format #71359

merged 10 commits into from
Jul 1, 2022

Conversation

EgorBo
Copy link
Member

@EgorBo EgorBo commented Jun 28, 2022

Closes #71065

This PR adds the following global method to *.mibc - MibcConfig that stores key-value config like this (similar to AssemblyDictionary method):
image

When we merge multiple mibc we just take the first valid config for the merged mibc.

When we do "dotnet-pgo dump" it's displayed like this:

FormatVersion:     1.0
Os:                Windows
Arch:              x64
Runtime:           CoreClr

# Methods: 1382
# Methods with any profile data: 677
# Methods with 32-bit block counts: 0
# Methods with 64-bit block counts: 677
# Methods with 32-bit edge counts: 0
# Methods with 64-bit edge counts: 0
# Type handle histograms: 522 in 209 methods
# GetLikelyClass data: 0 in 0 methods
# Call sites where getLikelyClass is null: 253
# Call sites where getLikelyClass is unknown: 0
# Call sites where getLikelyClass returns data that devirtualizes: 269

Call-sites grouped by number of likely classes seen:

          0: [##########..........] 48.5% (253) - call-sites with 'null's
          1: [##########..........] 50.2% (262) - monomorphic call-sites
          2: [....................]  1.3% (7)
          3: [....................]  0.0% (0)
          4: [....................]  0.0% (0)
          5: [....................]  0.0% (0)
          6: [....................]  0.0% (0)
          7: [....................]  0.0% (0)
          8: [....................]  0.0% (0)
          9: [....................]  0.0% (0)
        ≥10: [....................]  0.0% (0)


Likelihoods of the most popular likely classes:

  [ 0- 10%]: [##########..........] 253
  (10- 20%]: [##..................] 47
  (20- 30%]: [....................] 9
  (30- 40%]: [#...................] 14
  (40- 50%]: [....................] 4
  (50- 60%]: [....................] 0
  (60- 70%]: [....................] 0
  (70- 80%]: [#...................] 39
  (80- 90%]: [....................] 7
  (90-100%]: [######..............] 149

Generated pgo2.mibc.txt

@EgorBo
Copy link
Member Author

EgorBo commented Jun 28, 2022

Let me know if I e.g. should serialize it to e.g. JSON or CSV and put into a single ldstr or if there is a way to write the whole thing to a sort of manifest and stuff like that.

@MichalStrehovsky
Copy link
Member

One could also serialize this info as custom attributes. The ldstr/pop and ldtoken/pop is used for the rest of the MIBC stuff because it's more compact than custom attributes. We don't care about compactness for metadata that much. Custom attributes look nicer when looked at in e.g. ilspy. One could use AssemblyMetadataAttribute from mscorlib so that it even nicely resolves to something.

But not sure if it's a scenario we need to optimize for and you already wrote the code to use ldstr/pop...

@EgorBo EgorBo requested review from davidwrighton and jakobbotsch and removed request for davidwrighton June 28, 2022 13:58
src/coreclr/tools/dotnet-pgo/Program.cs Outdated Show resolved Hide resolved
config.Arch = processInfo?.PayloadByName("ArchInformation")?.ToString();

// Look for Sku, e.g. "CoreClr"
TraceEvent runtimeStart = p.EventsInProcess.Filter(t => t.EventName == "Runtime/Start").FirstOrDefault();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does the Sku work (what does it stand for)? It would be nice to have the mono runtime be emitted, so if we use the Sku for emitting runtime, would it be unproblematic to extend the Sku enum to also contain Mono (not sure if there is a trickle effect)? What is the Runtime/Start event/where do i look to find it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't sure what to pick for runtime so probably it would be easier if you tell me which event to analyze cc @lateralusX
I just opened a random nettrace via PerfView and searched for CoreCLR - this was the first thing to pop up - I assume mono runtime is expected to send this exact event on start with a different value for Sku

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If that eventname is the same as FireEtwRuntimeInformationDCStart, it seems to be the right event. I think we can try adding mono to the Sku Enum, right now we are emitting CoreCLR as well on Mono

RUNTIME_SKU_CORECLR,
since it wasn't clear whether a non 0x1, 0x2 Sku value will cause problems anywhere that its used.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see FireEtwRuntimeInformationDCStart in my sample nettrace

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is the events we collect - Microsoft-Windows-DotNETRuntime:0x1F000080018:5

Copy link
Member Author

@EgorBo EgorBo Jun 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I assume the current impl is correct as is, right? it does poll "Runtime/Start" event and extract Sku so once Mono is added we're all set

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lateralusX @EgorBo I'm thinking the value should be 0x4 as 0x3 will show up as DesktopClr, CoreClr since it matches those bits (0x1 || 0x2). I obtained a trace with --providers Microsoft-Windows-DotNETRuntime:0x1F000080018:5 on mono and it indeed shows the sku value within the mibc file. https://gist.github.com/mdh1418/2e9ad2d937dbdd0fb0be063c15eff61a

I also verified that we should be able to obtain the actual Sku value from the Mono AOT Compiler side as well. I'll put up a separate PR to integrate the .mibc file validation.

I think we should extend the relevant Sku structs and Mono additions I mentioned earlier

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is anything treating the sku as a bit set? Seems like it shouldn't be.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakobbotsch I'm not sure what the main rationale is between making something a bitmap vs a valuemap, but this might be why its behaving as such

<bitMap name="RuntimeSkuMap">

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, seems reasonable then.

Copy link
Member

@jakobbotsch jakobbotsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, couple of nits you can consider

@EgorBo EgorBo closed this Jun 28, 2022
@EgorBo EgorBo reopened this Jun 28, 2022
Copy link
Member

@mdh1418 mdh1418 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realized I forgot to submit the comments so all of my comments were pending 😅

config.Arch = processInfo?.PayloadByName("ArchInformation")?.ToString();

// Look for Sku, e.g. "CoreClr"
TraceEvent runtimeStart = p.EventsInProcess.Filter(t => t.EventName == "Runtime/Start").FirstOrDefault();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I extended the Sku Enum to have Mono 0x4 in both src/coreclr/inc/eventtracebase.h and src/coreclr/nativeaot/Runtime/eventtracebase.h

typedef enum _Sku
{
    DesktopCLR=0x1,
    CoreCLR=0x2,
    Mono=0x4
}Sku;

and the generated .nettrace is still compatible with perfview and visual studio (as in no throws or crashes from viewing the .nettrace). The only catch is that the value of Sku is literal Sku="4" compared to Sku="CoreClr" and Sku="DesktopClr". I believe that is because the libraries define the Sku as RuntimeSku with only enum vars for 0x1 and 0x2. https://github.com/microsoft/perfview/blob/8f5c46ad3980ecbd8845bff274911ecb22f98f3f/src/TraceEvent/Parsers/ClrEtwAll.cs.base#L6902-L6906

I'm not sure if there are other tooling or more advanced usages of .nettrace Rundown Runtime/Start events that leverage the value of Sku, but if this is the only extent, then it looks like we are good to go to with using the event.

@EgorBo can we include extending the Sku in this PR?

typedef enum _Sku
{
    DesktopCLR=0x1,
    CoreCLR=0x2,
    Mono=0x4
}Sku;

in both src/coreclr/inc/eventtracebase.h and src/coreclr/nativeaot/Runtime/eventtracebase.h
and changing the
#define RUNTIME_SKU_CORECLR 0x2 to #define RUNTIME_SKU_MONO 0x4

#define RUNTIME_SKU_CORECLR 0x2

as well as the rundown event Sku value
RUNTIME_SKU_CORECLR,

to be RUNTIME_SKU_MONO

config.Arch = processInfo?.PayloadByName("ArchInformation")?.ToString();

// Look for Sku, e.g. "CoreClr"
TraceEvent runtimeStart = p.EventsInProcess.Filter(t => t.EventName == "Runtime/Start").FirstOrDefault();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lateralusX @EgorBo I'm thinking the value should be 0x4 as 0x3 will show up as DesktopClr, CoreClr since it matches those bits (0x1 || 0x2). I obtained a trace with --providers Microsoft-Windows-DotNETRuntime:0x1F000080018:5 on mono and it indeed shows the sku value within the mibc file. https://gist.github.com/mdh1418/2e9ad2d937dbdd0fb0be063c15eff61a

I also verified that we should be able to obtain the actual Sku value from the Mono AOT Compiler side as well. I'll put up a separate PR to integrate the .mibc file validation.

I think we should extend the relevant Sku structs and Mono additions I mentioned earlier

@EgorBo EgorBo merged commit 9b10634 into dotnet:main Jul 1, 2022
@lateralusX
Copy link
Member

lateralusX commented Jul 4, 2022

@mdh1418 We should extend ClrEtwAll.man with the new enum values as well as strings. Since this PR has been merged, we need do it in separate PR.

Once we have the ClrEtwAll.man extended, we should also make sure perfview and EventTrace library correctly handles the new enum value. @brianrob can guide you through the steps needed to update these libraries in order to align to extensions to ClrEtwAll.man.

@ghost ghost locked as resolved and limited conversation to collaborators Aug 7, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Include runtime flavor and platform information into .mibc Profile
6 participants