Atomic operations were previously broken. RISC-V breaks atomic
operations into multiple instructions, and there is some state kept
between those instructions. This state is not visible, and is internal
to the processor.
We were ignoring this state, which resulted in inconsistencies
throughout the system. The following sequence was possible:
1. A thread loads a value, and obtains the `reservation set`
2. A context switch happens on the following instruction
3. A different thread loads the value, modifies it, and continues
4. A third thread (or a different process) loads a value and obtains the
`reservation set`
5. The original thread runs, sees the `reservation set` is held, and
updates the value, clobbering what the second thread did in #3
A workaround for this is to perform a dummy `sc` as part of the context
switch. This invalidates any atomic operations that may be pending.
Signed-off-by: Sean Cross <sean@xobs.io>
The previous patch didn't properly restore thread IDs when switching
contexts -- there were spots where we missed things, and spots where we
were double-borrowing.
Fix these corner cases.
Signed-off-by: Sean Cross <sean@xobs.io>
Note the current thread in the original process when its quantum
expires. This will allow us to clean up after ourselves when a context
switch occurs, and will help to prevent thread starvation.
Signed-off-by: Sean Cross <sean@xobs.io>
Currently, returning a Message (e.g. a Scalar1, Scalar2, or
MemoryMessage) always results in a context switch from the server to the
client. This is what makes these syscalls cheaper.
However, this results in process starvation. For example, if three
processes send a message to a server, then the server will only be able
to respond to one of those messages at a time. This works well with a
lightly-loaded system, but quickly falls apart when many threads are
running.
Keep track of which process and thread were originally switched to as
part of the `SwitchTo` call. If the Server is responding to a message
and owns the current quantum, don't immediately switch to the Client
thread.
Signed-off-by: Sean Cross <sean@xobs.io>
For some reason, the current thread becomes 0 during suspend or resume.
This causes an error during boot.
Patch this up while we figure out what's causing it.
Signed-off-by: Sean Cross <sean@xobs.io>
Unify scalar return calls so that we only have one return path rather
than three.
We can almost unify memory returning as well, but it's not quite there.
Signed-off-by: Sean Cross <sean@xobs.io>
There were a few corner cases when it came to thread selection. Namely,
the same thread had a higher chance of repeatedly being executed.
Clean up these corner cases, and as a result get libstd tests to pass.
Signed-off-by: Sean Cross <sean@xobs.io>
Add notes on how to properly hand memory to userspace. This does not yet
work, but is committed here as a work-in-progress.
Signed-off-by: Sean Cross <sean@xobs.io>
The default mem size got shrunk down to 4 MB earlier, but there is a
lingering issue that prevents specifying virtual addresses. As a result,
pddb and others don't work.
Temporarily revert this change.
Signed-off-by: Sean Cross <sean@xobs.io>
The process search now uses iterators properly. It's still not ideal
because it needs to investigate every process, but it's better than it
was.
Signed-off-by: Sean Cross <sean@xobs.io>
Use a multiply-based algorithm to count the number of leading zeroes.
This results in a function that's just 20 instructions long.
Signed-off-by: Sean Cross <sean@xobs.io>
THe act of finding a runnable thread is so common, yet the kernel
contains three ways of doing this.
Use a unified function to select the next available thread.
Signed-off-by: Sean Cross <sean@xobs.io>
Previously the `current_thread` was set to 0, which is invalid. Set the
`current_thread` so that it defaults to the initial thread ID.
Signed-off-by: Sean Cross <sean@xobs.io>
This memory region is much smaller than the previous value of 256 MB,
but it will limit the amount of memory used by superpages in
long-running processes.
Previously, we would march through memory as messages were passed back
and forth and a process' memory space would quickly be eaten up by 1024
pages.
Signed-off-by: Sean Cross <sean@xobs.io>
When waiting on a thread, it may be the case that the thread we're
joining has exited already. In this case, the correct approach is to
resume execution rather than switching to the parent process.
This fixes an issue where `SWITCHTO_CALLER` is None when joining a
short-lived thread.
Signed-off-by: Sean Cross <sean@xobs.io>
When attempting to return an invalid item, return `DoubleFree`. This is
because such cases are most likely due to instances where a message was
responded to twice.
Signed-off-by: Sean Cross <sean@xobs.io>
- we don't need a general memset call -- just a zero page call
- use native rust semantics to embody the call. some alignment checking is
done on the arguments on the way in and out that seem worth it
- the unrolled loop doesn't pay off because we're at the limit of
write bandwidth on the CPU at this point. we would need write-back
caches to gain more performance through unrolling.
@xobs found a scheduler bug that would trigger a runnable process
search every time a scalar message returned. This fixes the problem,
causing the quantum to go back to the caller as intended.
Improves performance on the syscall by about 40%.
Fix a segfault that occurred when using ReplyAndReceiveNext on hosted
mode. This now properly passes memory messages back to the client.
Signed-off-by: Sean Cross <sean@xobs.io>
Implement `ReplyAndReceiveNext` as a syscall. This will reply to a
message, pull the next message out of the queue, and then re-queue the
server to run. This should make servers much more responsive.
This patch has been tested on both hosted and native modes.
Signed-off-by: Sean Cross <sean@xobs.io>
