-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
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
GH-126892: Reset warmup counters when JIT compiling code #126893
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The warmup numbers are going to be wrong once #126816 is merged.
Do you want to get that merged first, then update this. Or the other way around?
I'll do that then this. |
Fixed the tests (I also needed to change the logic a bit since the bytecode re-specializes before we JIT a new trace). |
__run_using_command=[_strace_binary] + strace_flags) | ||
__run_using_command=[_strace_binary] + strace_flags, | ||
# Don't want to trace our JIT's own mmap and mprotect calls: | ||
PYTHON_JIT="0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Guessing this showed up in the test_fileio
test test_syscalls_read
?
I have been keeping an eye on / working through a couple other issues where mmap(NULL) and mprotect show up, trying to figure out if just excluding those two from that test would be good/effective (memory allocation happening in reading files is fine / not what the test is focused on).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was wondering if this was susceptible to catching badly-timed arena allocations and such too. Might make sense to have an option to ignore the mmap
/munmap
/mprotect
family of functions instead of this ad-hoc fix.
I'm just not familiar with how this is being used, and didn't want to change the meaning/behavior of the tests too dramatically.
19% fewer traces created, no change in uops executed. No performance impact.