-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
build.cmd does not regenerate managed PGO data on changes #53637
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Think this is a build system issue, somehow we need to understand that the optimization data is out of date -- basically the step that restores the data needs to be dependent on the props file or something, so it reruns if the props file changes. |
@jakobbotsch do the files in artifacts/mibc change across those builds? I believe our build infra is designed to detect changes to those, but I'm not confident about the bits in artifacts/mibc getting updated correctly. |
@davidwrighton Yes, it seems like those files do change. |
The problem seems to be that the timestamps of the files in artifacts/mibc are the original timestamps from inside the NuGet package. That means they are days in the past. Once we create the merged StandardOptimizationData.mibc, the timestamp becomes the time at which the tool was invoked. When we get newly optimized data in artifacts/mibc this still remains older than StandardOptimizationData.mibc, and thus it doesn't rerun. Ideally the artifacts/mibc/**.mibc files would have their timestamp reset when they are placed, but that does not seem that easy to do while keeping incremental builds (it would be better if we could set the times after package restore has determined a new optimization data package was needed). Instead, I guess we can change the merged output .mibc file timestamp to be the same as the input files. Then at least dotnet-pgo will rerun automatically when one fetches newer commits (but potentially not if going back in history). |
The timestamp of the merged .mibc file was set to when the tool was invoked, while the inputs have a timestamp from when they were created in the training scenarios. That means the target to create the merged .mibc file would not run incrementally until many weeks later. To fix add an --inherit-timestamp flag to dotnet-pgo that makes the merged output inherit the max timestamp from the inputs. This is not ideal as it means incrementally going backwards does not work, but it's better than the previous behavior. Fix dotnet#53637
The timestamp of the merged .mibc file was set to when the tool was invoked, while the inputs have a timestamp from when they were created in the training scenarios. That means the target to create the merged .mibc file would not run incrementally until many weeks later. To fix add an --inherit-timestamp flag to dotnet-pgo that makes the merged output inherit the max timestamp from the inputs. This is not ideal as it means incrementally going backwards does not work, but it's better than the previous behavior. Fix #53637
StandardOptimizationData.mibc does not seem to be regenerated when it exists, even when the opt data package changes:
d435388 is a commit where the PGO data changed significantly.
cc @davidwrighton @AndyAyersMS
The text was updated successfully, but these errors were encountered: