| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
+ The secret is using gravestones. I'll have to write up full
documentation for the feature but essentially riscv lets us encode
whatever we want into page table entries, as long as they're not
active. We use this to encode highest user address that is not a zero,
in that all entries in the top level are either active or gravestones.
When an active entry is removed, it is either a gravestone (if there
are other active entries above it) or it starts a cascade of removing
entries that have been previously removed
Slight runtime overhead to page mapping, pretty major advantage in rpc
calls. Feature will need to be tested more thorougly, and the init
program is sort of a best scenario with just one top level userspace
page table entry active at a time, leading to incredibly fast context
switches.
Current implementation limits a process' max virtual memory to 248 GiB
(in Sv39), but I don't think the missing 8 GiB is that big of a deal.
|
|
+ Both easier to look at and now the userspace doesn't play as big of a
role in the 'benchmarking' with optimizations turned on.
|
|
|
|
+ Not strictly done yet, but we can swap between two processes :D
|
|
+ Not actually working (at least fully), need to continue debugging when
I have time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+ Slightly unsure if it should be a syscall, or if assign would be
enough. Also, which thread should run in a fork/spawn? For now, old
thread, though this might increase latency. Or add swap flag to these
calls?
|
|
|
|
+ Prefer over unixy fork/exec for speed since I don't want to support
cow. Shell redirection should be done with env server and cooperating
libc.
|
|
+ Skip cow for now, maybe implement later but try to keep things simple.
|
|
|
|
+ Multiple notify signals at the same time, or queued ones waiting for
ipc_req/fwd to finish would require a notify stack of some kind, which
is maybe too complex for my liking. Not impossible by any means, but I
want to keep things simple.
Let's say a client wants the server to do some async operation. First,
the client calls ipc_req to inform the server that it would like the
operation to be done. The server sets this task in some work queue or
whatever, and returns to the client as quickly as possible. Later on,
when the task is finished, the server does a ipc_req to the client,
with data about what was just finished. The client is responsible for
noting this data down somewhere, either reacting to the operation
directly in the callback, or calling ipc_notify to the thread that
requested the operation. Other possible notifications at the same time
should be handled at the same time, whichever way the client wants to
handle them.
Note that ipc_notify triggers only when the thread it targets is in
its base state, i.e. not doing an ipc_req. This makes things a bit
easier.
|
|
|
|
+ Now to actually start implementing shit. :)
|
|
|
|
+ In total, a syscall is built up of 6 values, with the first being the
syscall number. Symmetrically, the first value is now a status and the
following five values return "values". This allows us to cram in more
info into the ipc_* functions. The performance difference is
absolutely minimal, at least from my testing in qemu.
|
|
|
|
+ Note that it is NOT intended for end user usage, just for debugging.
|
|
|
|
|
|
|
|
+ Does not mean documentation is done, but it's a nice little
achievement nonetheless.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+ Essentially, separate root process and remote procedure call handling.
I really should write down some documentation so I don't forget, but
essentially: All threads share a common process virtual memory, and
when a thread wants to make an rpc, it switches over to its own rpc
vmem space that is linked to the remote process.
|
|
|
|
|
|
|
|
|
|
The output is close enough, and I like that uncrustify is a third-party
tool, so people can install a single tool for formatting instead of
having to lug around a whole toolchain. I fully expect to have to add
settings to uncrustify.conf, but let's see how this goes.
|
|
|
|
+ Next step, start documenting contents of each file.
|
|
|
|
|
|
+ next up would probably be to start working on process/thread
relationships, largely as documented. Still not entirely sure about
how I want to handle fork, but I suppose I might figure it out at some
point.
|
|
|
