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
Just like OS can map device's memory into address space accessible by the process, I'm wondering if something similar could be done here to avoid memory copies.
For example I might have a piece of memory allocated by the host, then call a few different programs that manipulate that memory directly instead of copying it to and from each program's memory every time.
This could make use of address space beyond 32-bit, such that memory allocations with sbrk do not collide with it. Otherwise host can't even allocate memory without active cooperation with guest's allocator, which is an annoying level of coupling and with probably make it harder to use generic memory allocators.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Just like OS can map device's memory into address space accessible by the process, I'm wondering if something similar could be done here to avoid memory copies.
For example I might have a piece of memory allocated by the host, then call a few different programs that manipulate that memory directly instead of copying it to and from each program's memory every time.
This could make use of address space beyond 32-bit, such that memory allocations with
sbrk
do not collide with it. Otherwise host can't even allocate memory without active cooperation with guest's allocator, which is an annoying level of coupling and with probably make it harder to use generic memory allocators.Does this make any sense?
Beta Was this translation helpful? Give feedback.
All reactions