Too high attribution to PollGCWorker or P/Invokes in general

I'm using EventPipe profiling for continuous profiling and since moving to .NET 10 I start to see System.Private.CoreLib!System.Threading.Thread.<PollGC>g__PollGCWorker taking 70-80%. I'm using programmatic DiagnosticClient + TraceLog, but I have verified this with plain dotnet trace collect and PerfView viewer, the result is the same.

I was using a custom collectible AssemblyLoadContext, but I have just verified that the behavior remains with the Default ALC and with a custom non-collectible one.

Previously, I've noticed a similar issue with other native calls. E.g. P/Invoke to memmove inside overlapped Array.Copy or zeroing inside Array.Clear showed about 40% and 25% of the total time. Optimizing these parts improved the look of the profiling output (these ballooned items disappeared), but did not improve the total execution time by near as much, maybe by several %.

Since PollGC is a new addition in .NET 10 and uses P/Invoke, I have a suspicion that this is related to such native calls in general and not specifically to PollGC.

The dotTrace profiling of the same workload shows PollGC at some noise level as it should be, so the current output of EventPipe is barely usable. I need to filter out all these ballooned lines and can trust only the ordering and relative values of the remaining nodes.

I could not find anything specific related to this issue, so I'm posting here. Is this a known behavior? Is there a workaround for this?

    <PackageReference Include="Microsoft.Diagnostics.NETCore.Client" Version="0.2.661903" />
    <PackageReference Include="Microsoft.Diagnostics.Tracing.TraceEvent" Version="3.2.2" />

Start by reproducing the attribution with plain dotnet trace collect and the PerfView viewer, then compare it with the same workload under dotTrace. Use the programmatic DiagnosticClient + TraceLog path as a second comparison, and consider the PollGCWorker and the reported memmove and Array.Clear P/Invokes; done means identifying whether EventPipe attribution is wrong and documenting a confirmed fix or workaround.