ETW Event for InitializeYieldProcessorNormalized

[brianrob]

Emit an ETW event containing the values computed by InitializeYieldProcessorNormalized when:

1. InitializeYieldProcessorNormalized calculates its values.
2. An ETW session is started that requests the values computed by InitializeYieldProcessorNormalized

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[kouvel]

Doesn't seem worth using a different keyword for this, can it go into the Threading keyword? The event may or may not be sent after relevant fixes are made.

[kouvel]

The values computed in .NET Framework are different. I suggest sending just the nsPerYield value as an 8-byte float, that is commonly measured in .NET Framework and .NET Core, and the rest of the values can be calculated from it.

[stephentoub]

My understanding is we no longer have faith in the methodology employed by InitializeYieldProcessorNormalized. If that's true, shouldn't we be removing it / replacing it rather than adding an ETW event that tracks its result?

[brianrob]

The general idea here is that we're not necessarily going to replace InitializeYieldProcessorNormalized everywhere, and so anywhere that we don't remove it, we should add this event. This allows us to use it as a canary when investigating performance issues that might be due to the values that were calculated here. Also until we do replace the implementation, this allows us to do the same thing in .NET 6 builds.

[stephentoub]

so anywhere that we don't remove it, we should add this event

Does that mean we don't plan to remove it from .NET 6?

[brianrob]

I do believe that we plan to replace this in .NET 6. I have not seen a timeline yet, and so my default path is to create a PR into main, and then backport. Totally fine to pull this out of .NET 6 when we replace the functionality, but until then, it's a useful event to have. Also, we'll want to make sure that we reserve the event ID in .NET 6 and beyond so that we don't overload the event ID in the future. So we will need at least some portion of this PR (the manifest change) to do that.

[stephentoub]

What do we plan to do with the data if we're not going to use this approach in .NET 6+? If we really believe it's useful, I'm ok adding it. It just seems like it's going to be instant legacy, and I'm not clear what we're going to do with data we get from a backport.

[kouvel]

An event is being added along with a fix in #55295