Set specific sliced pages for read-only threads in EOS VM OC Tierup #1498
Conversation
…ierup and OC runtime do not create slices at the same time
Can you add a verification to the test? |
| } | ||
|
|
||
| eosvmoc::code_cache_async cc; | ||
|
|
||
| // Each thread requires its own exec and mem. | ||
| thread_local static std::unique_ptr<eosvmoc::executor> exec; | ||
| thread_local static eosvmoc::memory mem; | ||
| thread_local static std::unique_ptr<eosvmoc::memory> mem; |
There was a problem hiding this comment.
(obviously not in this PR) but I'd really like for us to noodle on how to move away from these thread_locals, they have dangerous lifetime semantics imo. In this particular example, when eosvmoc_tier is destroyed, cc is destroyed, but the exec created with a reference to that cc lives on. So if executor's dtor (which will run well after eosvmoc_tier's dtor) touches the code_cache_async that was passed to it via reference: bad news! It's a real trap -- passing a reference to some object to the ctor of an object implies that reference will be valid for the lifetime of the object.. but it's not true here.
There was a problem hiding this comment.
Thanks. I will be looking into moving away from those thread_locals.
There was a problem hiding this comment.
I created #1503 to track this. Will work on it soon.
… as the number of read-only threads increases
|
|
||
| def verifyOcVirtualMemory(): | ||
| try: | ||
| with open(f"/proc/{apiNode.pid}/statm") as f: |
There was a problem hiding this comment.
I realize it doesn't matter now since OC is linux only, but it might be nice to skip this test on non-Linux if that's easy to do.
#1488 missed setting specific sliced pages for read-only threads in OC tierup.
This PR
Before the PR,
nodeosrunning the integration testread-only-trx-parallel-eos-vm-oc-test(with 6 read-only threads) uses 29 TB virtual memory; after the PR, it uses 4.7 TB virtual memory as expected.