Mill Computing, Inc. › Forums › The Mill › Architecture › IPC questions
- AuthorPosts
- #3031 |
Very interesting talk as usual Ivan, tx for sharing.
In earlier talks, you mentioned that local addresses had the turf id embedded and to globalize it you xored it with the address. From this talk, I get the impression that your approach has changed and now you keep the turf starting point in a dedicated register. Can you confirm the approach changed? (I hope it did, the xor thing seemed really awkward when forking).
When you issue a portal call, I assume the address is a global pointer. At the other end of the portal, the turf starting address register needs to be updated. How does the hardware determine the new turf address during the portal call? Is there a per process table somewhere mapping portals to turfs?
When you fork, I assume you don’t actually duplicate the code. So the same code can be shared by 2 different turfs right? data access will be local so it will pick up the data from right turf, but the code itself is shared right?
Do you COW data during a fork? I would assume the OS needs to be involved via a fault for that.
Lets say you want to write to a file. The application would issue a grant and then a portal call with the address of the buffer. That address would typically be local and would have to be globalized, so is there an operation to globalize and localize addresses? or somehow the portal call can figure out what to globalize?
Tx for you time Ivan, the mill is just so interesting to learn about 🙂
Lots of questions!
The local and global address spaces are address spaces, not turfs. Yes, when a fork happens the parent’s local space is logically replicated (yes, COW) in the child, and the child turf gets the same rights into it that the parent turf did to its copy, but many different turfs may have rights into the respective spaces. Spaces are an aliasing notion, not a permission notion.
XOR still exists; it cheaply permits bi-directional change from local to global addressing.
It’s OS/RTS policy whether code is (COW) duplicated or is shared. Normal loaded code will likely share, but if there’s a JIT in there then you might want to duplicate it. The hardware doesn’t care.
COW involves a protection trap (not fault), fielded by the Protection Service. Whether that is part of the OS or is a detached service is up to the system design. The fork() may also elect to pre-copy things that are certain to be touched right away, like the data stack. All policy.
There are ops to global-/local-ize pointers. We expect that portals taking pointers will be called through a shim that globalizes, and the callee will verify globalization as part of argument checking. There is hardware help for that, that will be covered in a future talk.
Doesn’t the XOR make it hard to fork?
It means the OS needs to find a turf id such that when globalizing addresses, they don’t overlap with global addresses that are already in use.
And what is it that you XOR? you have that register with the current turf, you xor that with a local pointer to globalize it? I guess I am a bit confused why you chose xor as opposed to simply adding, then the register essentially has the starting address of the current turf.
Turf’s don’t have addresses, they have ids. The turf is a collection of arbitrary address ranges with their permissions.
Yes, when allocating in local you have to not collide in global; there’s lots of address space. What is XOR’d is the turf id into the high bits of the address. This relies on each Unix process (the only code that has fork()) having a new “home” turf for each process.
Very cool.
I have never seen an architecture that can do IPC without involving the kernel. Had that been available 20 years ago, the operating systems today would be very different.
When are we going to have the sim available? I am dying to play with it.
- This reply was modified 7 years, 2 months ago by goldbug.
Patience, waiting is.
- AuthorPosts
You must be logged in to reply to this topic.