You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Look at mapping the interpreter's code in huge pages #20
It looks as though the CPU has two pieces of iTLB hardware. One for huge pages and one for small pages. If that's true, we could benefit from having the interpreter use the huge pages, and the JIT use the small pages all for itself. This is a patch that we could also potentially upstream. It could benefit CRuby and MJIT as well.
@XrXr Since remapping the text segment is complicated. I think it make sense to focus on maybe just trying to mmap the microjit code into huge pages and test the performance for now.
We could leave text in normal pages, and have the JIT code in the huge pages, ideally allowing us to use both TLBs at once, an avoiding a complex, less portable solution.
If you try this, I would suggest using the code from the microjit-v1 branch, since the current branch is in flux and not ready to be benchmarked right now.
Activity
[-]Map the interpreter's code in huge pages[/-][+]Look at mapping the interpreter's code in huge pages[/+]maximecb commentedon Jan 18, 2021
@XrXr Since remapping the text segment is complicated. I think it make sense to focus on maybe just trying to mmap the microjit code into huge pages and test the performance for now.
We could leave text in normal pages, and have the JIT code in the huge pages, ideally allowing us to use both TLBs at once, an avoiding a complex, less portable solution.
If you try this, I would suggest using the code from the
microjit-v1branch, since the current branch is in flux and not ready to be benchmarked right now.maximecb commentedon Jan 21, 2021
Closing this for now since it doesn't look like mapping the text segment in huge pages is worth the added complexity.
Might be worth revisiting mapping the JITted code in huge pages (simpler) once MicroJIT V2 is further along.
check ep during compaction because it can be null
check ep during compaction because it can be null
Implement dupn for n==2 (only case used in RDoc/railsbench) (#20)
[ruby/strscan] Fix segmentation fault of `StringScanner#charpos` when…
check ep during compaction because it can be null
Merge upstream Ruby (#25)
Implement dupn for n==2 (only case used in RDoc/railsbench) (#20)
Implement dupn for n==2 (only case used in RDoc/railsbench) (#20)
Implement dupn for n==2 (only case used in RDoc/railsbench) (#20)
Implement dupn for n==2 (only case used in RDoc/railsbench) (#20)
Implement dupn for n==2 (only case used in RDoc/railsbench) (#20)
merge revision(s) 564ccd0: [Backport ruby#17756]
[ruby/openssl] Stub gemspec for JRuby
Fix use-after-free in constant cache
Fix use-after-free in constant cache
Fix deadlock when malloc in Ractor lock
ns_subclasses refcount accesses need to be atomic (ruby#15083)
ns_subclasses refcount accesses need to be atomic (ruby#15083)
merge revision(s) f65a6c0: [Backport #20921]
Fix use-after-poison