| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
+ The simulated benchmarks shows very slightly more than 2M
requests per second, new record!
|
|
+ Gives a hint to the LTO optimizer to more agressively inline the functions,
seems to bring a slight performance increase
|
|
|
|
+ Speeds up fork a little bit
|
|
|
|
|
|
|
|
+ Worked in qemu, failed in visionfive2, fixed.
|
|
+ Processes won't be able to read previous stack frames etc
|
|
|
|
|
|
|
|
|
|
+ Now each shared region is reference counter (technically each region
is refernce counted, private regions just have a count of 1).
Also, syscalls that touch the TLB get flushed, but should probably
look into where else this flushing might be needed.
|
|
+ get_mem_node() clears out the memory so we don't accidentally read
stale flags
+ Thread creation simplified a bit, each thread references itself
and data freeing is based on when the reference count reaches zero.
|
|
+ Skip unwinding stack and just jump directly to userspace
|
|
|
|
+ Apparently primary bottlenecks for sys_fork() and sys_create(),
speeds things up quite a bit
|
|
|
|
|
|
|
|
+ Remove sys_kill() as we should be using a two-stage process where a
thread is first orphaned by sys_detach(), and then the thread itself
calls sys_exit() after it has done all necessary cleanup in init.
|
|
+ A bit easier to implement just ignoring the ipc_resp() arguments than
try to enforce that a notification is exited from by ipc_ghost(),
especially in cases where the root process has been killed.
|
|
|
|
|
|
+ Currently analyzer has to be run manually with something like
make CFLAGS='-fanalyzer -Wno-analyzer-infinite-loop'
I use an infinite loop as an assert, I know it's not great/technically
UB but it's just a fallback.
+ Analyzer is still somewhat limited, I could add in more
attributes about different functions, such as memory allocation sizes
etc.
+ If I ever set up a CI pipeline, remember to use analyzer?
|
|
+ Seems to improve code quality a little bit
|
|
+ ipc_kick() does a forward and a tail at the same time
The idea with ipc_tail() is to allow 'trusted' calls, so for example a
process is not allowed to willy-nilly open a file, as it has to go via
init(), making the eid 1. This way the receiver can know that the
request has gone through init() and can open up a new connection
(file, whatever) after which requests from that pid/tid are allowed
without init() intervention
|
|
|
|
+ Can be used to build fast hashmaps to speed up ipc
|
|
|
|
|
|
|
|
+ Current setup will likely not last long, just a stopgap until I figure
out how I want to build each testcase etc.
Probably dir based, but I'll probably add some scripts that generate
the build rules for each test case (or binary?). Also, should probably
put ouput files in a build directory and keep the source clean, but
again, good enough for now.
Will have to start implementing more extensive tests, and probably
come up with some way to compare textual output etc.
|
|
+ A reserved area is an area at the start of the region that should not
be used unless explicitly asked for, for example null pages.
As such, a small correction to my previous commit message: There's no
danger in not locking req_mem() etc, as a null page will only be
allocated when explicitly asked for.
|
|
+ User has to 'free' the 0 page before it becomes accessible to mapping.
Probably worth noting that this is likely VERY niche and mainly
concerns stuff like certain kinds of emulators that I'm still
eons from implementing, but still.
Unbacked pages can also be useful for some kinds of notifications,
like 'if someone writes to this page, please report it to me with this
ID' or whatever, I remember seeing some discussion about it somewhere
but that's also not really relevant for the moment.
Most significantly, at least with the current design,
after the null page is freed it becomes available for use to regular req_mem()
calls, so users should probably using locks around memory requests.
That's probably a good idea anyway as internally the kernal has to
lock the virtual memory, and without a scheduler it might cause
threads to spin for a while in the kernel which is rather bad.
|
|
+ Anything extern is right out as LLVM doesn't produce correct code for
them. Maybe if I added some extra attributes but I'm skeptical.
Replaced with static variables and getters/setters.
+ Inline ASM is apparently a bit buggy, so use an assembly stub when jumping to init.
+ Minimize work done in main() to minimize chance of LLVM doing something silly.
Still not 100% certain that I shouldn't just write the main() as an assembly stub
in arch/riscv64 to be absolutely sure everything works as intended.
+ Make .kernel.start section SHF_ALLOC, otherwise lld complains about
pc-relative addressing
Probably some other stuff as well that I'm forgetting right now. But at least with
LLVM14 LTO seems to work, which is pretty cool?
|
|
|
|
+ Can be used to pass contiguous memory regions to things like virtio
block devices for implementing disk drivers etc.
|
|
+ Effectively means that all executables can be called into, but if an
exe doesn't want to deal with anyone else it should just set a flag
like `not_really_a_server` or whatever
|
|
+ Align kernel to 2MiB boundary in u-boot
+ Optimize alignment functions a little bit, should still have to check
on real hardware but 'feels' more clean
+ Add early boot debugging
+ Put extra cores we aren't ready to account for to sleep if/when they
boot.
+ Make BASE_PAGE_SIZE constant on riscv64/32, helps the compiler with
some alignment checks among other things.
|
|
+ No real point having multiple different levels of assertions, just say
you assert something and be done with it
|
|
+ Had some minor issues with a wraparound of size_t that effectively
meant that some regions were allocated twice. Also, booting should be
a bit more reliable now, turned out that the previous iteration of the
booting was just accidentally working due to the kernel being placed
'close enough' in RAM to where it was linked to. Fixed by allocating a
vmem of O1 that maps the kernel to a 2MiB boundary at boot, pretty
nifty.
|
|
+ Apparently dbg_fdt() itself wasn't buggy, but for whatever reason GCC
produced an absolute load to the prefix string in __print_prefix()
which caused all the issues. Unclear why, seems like a compiler bug.
This commit is more of a workaround, I'd still like to investigate
this further.
|
|
+ dbg_fdt() is apparently broken, possibly due to UB or something, but
it causes some issues with optimizations enabled. Remove it
temporarily
|
|
+ Slightly more overhead but will help track down possible memory leaks
in the future. Could also add in a flag for turning off/on but I don't
think the difference in performance is that significant.
|
|
|
