kernel issueshttps://gitlab.redox-os.org/redox-os/kernel/-/issues2024-03-17T20:29:57Zhttps://gitlab.redox-os.org/redox-os/kernel/-/issues/148Support generic interrupts on arm642024-03-17T20:29:57Zbjorn3Support generic interrupts on arm64See the thread starting at https://matrix.to/#/%23redox-dev%3Amatrix.org/%24hVX4XI4x2tbwbJCSl1vQ5wx0C7GOBNGfWTmXAtW6e3c?via=mozilla.org&via=matrix.org&via=artifact8.xyz&via=envs.net But basically only timer and serial interrupts currentl...See the thread starting at https://matrix.to/#/%23redox-dev%3Amatrix.org/%24hVX4XI4x2tbwbJCSl1vQ5wx0C7GOBNGfWTmXAtW6e3c?via=mozilla.org&via=matrix.org&via=artifact8.xyz&via=envs.net But basically only timer and serial interrupts currently work. The `irq:` scheme required by most PCI drivers (and other drivers) is non-functional. This needs to be implemented for each of the three irq chips supported by the kernel.https://gitlab.redox-os.org/redox-os/kernel/-/issues/147Support huge pages2024-03-16T10:21:13ZJacob Lorentzon4ldo2@protonmail.comSupport huge pagesHuge pages are heavier, slower to CoW, and possibly wasting memory, and would waste 0.4% being unused `PageInfo`s. But they do almost always reduce TLB overhead, and most importantly, they require far less page table mappings and flushes...Huge pages are heavier, slower to CoW, and possibly wasting memory, and would waste 0.4% being unused `PageInfo`s. But they do almost always reduce TLB overhead, and most importantly, they require far less page table mappings and flushes than small pages. That means they can potentially, in some cases, be a huge improvement (512x for 2 MiB pages) in IPC latency and to a lesser extent, throughput. 1 GiB pages may also allow (recently-used) physical addresses to hopefully always reside in at least the L2DTLB in kernel mode, speeding up e.g. copying of pages. Jeremy measured the optimal buffer size for throughput, (for most schemes including redoxfs), was 4 MiB, with larger sizes being slower due to mapping/flushing and possibly TLB overhead.
Worth noting AArch64 supports two additional standard page sizes -- 16 KiB and 64 KiB, which for some if not most workloads is more efficient, and 16k could maybe even be a better default. Ironically, Zen3+ AMD CPUs also support a 16 KiB page size, by merging any 4 virtually-contiguous pages that are physically contiguous and naturally 16k-aligned, into a single 16 KiB TLB entry. Although it would waste 4x as much page table memory, that might also be worth looking into.https://gitlab.redox-os.org/redox-os/kernel/-/issues/146Implement CPU softlockup and hardlockup detection2024-03-15T14:17:19ZRibbonImplement CPU softlockup and hardlockup detectionhttps://www.kernel.org/doc/html/latest/admin-guide/lockup-watchdogs.htmlhttps://www.kernel.org/doc/html/latest/admin-guide/lockup-watchdogs.htmlhttps://gitlab.redox-os.org/redox-os/kernel/-/issues/145Support process-context identifiers2024-03-11T15:24:56ZJacob Lorentzon4ldo2@protonmail.comSupport process-context identifiersPage table switching is a significant part of context switch overhead, which process-context identifiers help reduce. With [TLB shootdown](https://gitlab.redox-os.org/redox-os/kernel/-/merge_requests/282) now properly implemented, it wou...Page table switching is a significant part of context switch overhead, which process-context identifiers help reduce. With [TLB shootdown](https://gitlab.redox-os.org/redox-os/kernel/-/merge_requests/282) now properly implemented, it would be a natural extension to add a percpu queue of `Weak<AddrSpaceWrapper>`, and retain the address space CPU users bits set as long as they are still in that queue. PCIDs would only be used for userspace mappings, as the redox kernel memory layout makes a clear distinction between user and kernel addresses. An address space is user-accessible if and only if it's lower half, and if and only if it's non-Global.
Because this may impact TLB shootdown performance, it would need to be benchmarked thoroughly before being enabled at least by default.https://gitlab.redox-os.org/redox-os/kernel/-/issues/144Allow the kernel to log a panic message while the logger is still locked2024-02-27T10:44:41Zbjorn3Allow the kernel to log a panic message while the logger is still lockedNormally you can't log anything while the logger is locked to avoid multiple log messages from getting interleaved. When panicking the logger may never be unlocked as you may be panicking on the same kernel thread that holds the lock. Ge...Normally you can't log anything while the logger is locked to avoid multiple log messages from getting interleaved. When panicking the logger may never be unlocked as you may be panicking on the same kernel thread that holds the lock. Getting the panic message interleaved with other messages is much better than hanging without any panic message getting printed at all.https://gitlab.redox-os.org/redox-os/kernel/-/issues/143kernel hang on ls command with pipe2023-12-13T18:39:56ZRon Williamskernel hang on ls command with pipe`ls -C /bin | less` seems to hang the kernel some times. It was seen twice in a row on Orbterm.`ls -C /bin | less` seems to hang the kernel some times. It was seen twice in a row on Orbterm.https://gitlab.redox-os.org/redox-os/kernel/-/issues/142Kernel as an user-space process2023-12-14T13:53:34ZRibbonKernel as an user-space processAllow the kernel to run in user-space to improve debugging, like [NetBSD](https://en.wikipedia.org/wiki/Rump_kernel) and [DragonFlyBSD](https://www.dragonflybsd.org/docs/handbook/vkernel/) does.Allow the kernel to run in user-space to improve debugging, like [NetBSD](https://en.wikipedia.org/wiki/Rump_kernel) and [DragonFlyBSD](https://www.dragonflybsd.org/docs/handbook/vkernel/) does.https://gitlab.redox-os.org/redox-os/kernel/-/issues/141Pipe events don't work when changing namespaces2023-12-13T18:39:56ZRon WilliamsPipe events don't work when changing namespacesIf you create a pipe, then call mkns and setrens, then register for events on the pipe, when the writer writes to the pipe, the scheme id used to look up the event queue will not match the scheme id in the file description.If you create a pipe, then call mkns and setrens, then register for events on the pipe, when the writer writes to the pipe, the scheme id used to look up the event queue will not match the scheme id in the file description.https://gitlab.redox-os.org/redox-os/kernel/-/issues/140Add a system call to delete a namespace2024-03-18T09:58:09ZRon WilliamsAdd a system call to delete a namespaceThere does not seem to be a system call to remove a namespace after use. Contain creates namespaces and should delete them when when the user session completes.There does not seem to be a system call to remove a namespace after use. Contain creates namespaces and should delete them when when the user session completes.https://gitlab.redox-os.org/redox-os/kernel/-/issues/139Save kernel memory after panic2023-12-14T13:53:49ZRibbonSave kernel memory after panicOn Linux the [kdump](https://en.wikipedia.org/wiki/Kdump_(Linux)) method is used to save the kernel memory to a file after a panic (crash dump), by doing this the kernel memory snapshot can be analyzed later (debugging).
This method giv...On Linux the [kdump](https://en.wikipedia.org/wiki/Kdump_(Linux)) method is used to save the kernel memory to a file after a panic (crash dump), by doing this the kernel memory snapshot can be analyzed later (debugging).
This method gives more information than crash logs.https://gitlab.redox-os.org/redox-os/kernel/-/issues/138Support restartable sequences2023-10-29T20:37:56ZJacob Lorentzon4ldo2@protonmail.comSupport restartable sequencesRestartable sequences are available on Linux, and would allow better spinlock performance, and possibly make it easier to move parts of the futex API to userspace (because atomic hashmaps are hard without using spinlocks at least *somewh...Restartable sequences are available on Linux, and would allow better spinlock performance, and possibly make it easier to move parts of the futex API to userspace (because atomic hashmaps are hard without using spinlocks at least *somewhere*).
This would likely be achieved by userspace providing its TCB page to the kernel. Such a page may also store sigprocmask and possibly the pending mask/signal arguments, if most of signal handling is moved to userspace.https://gitlab.redox-os.org/redox-os/kernel/-/issues/137Improve frame allocator performance2024-03-25T18:05:48ZJacob Lorentzon4ldo2@protonmail.comImprove frame allocator performance[Recent performance profiles](https://gitlab.redox-os.org/-/snippets/2225) of the kernel, suggest that the frame allocator is a major performance bottleneck. This can be improved by allocating frames in larger blocks, when single-frame a...[Recent performance profiles](https://gitlab.redox-os.org/-/snippets/2225) of the kernel, suggest that the frame allocator is a major performance bottleneck. This can be improved by allocating frames in larger blocks, when single-frame allocations are requested, or by optimizing the allocator itself.
Page fault readahead would also improve performance, but for regular allocations, the hardware page fault overhead and overhead from locking etc. is likely not yet significant enough for that.https://gitlab.redox-os.org/redox-os/kernel/-/issues/136Proper TLB management2024-03-05T02:29:09ZJacob Lorentzon4ldo2@protonmail.comProper TLB managementThe TLB is currently flushed much more often than necessary, which makes errors very unlikely, but TLB flushing is not synchronized across threads e.g. when deallocating/downgrading mappings, and not optimized. This is also required for ...The TLB is currently flushed much more often than necessary, which makes errors very unlikely, but TLB flushing is not synchronized across threads e.g. when deallocating/downgrading mappings, and not optimized. This is also required for future optimizations such as PCID.https://gitlab.redox-os.org/redox-os/kernel/-/issues/135Replace physalloc/physfree with a "physically contiguous" mmap or madvise flag2023-12-16T18:01:11ZJacob Lorentzon4ldo2@protonmail.comReplace physalloc/physfree with a "physically contiguous" mmap or madvise flagPhysalloc and physfree offer no checking of ownership, and while there could be "physical grants" to track raw physical allocations from drivers, it would be much cleaner to integrate it with the existing mmap code.Physalloc and physfree offer no checking of ownership, and while there could be "physical grants" to track raw physical allocations from drivers, it would be much cleaner to integrate it with the existing mmap code.https://gitlab.redox-os.org/redox-os/kernel/-/issues/134Move address space virtual address range allocation to userspace2023-10-31T14:56:21ZJacob Lorentzon4ldo2@protonmail.comMove address space virtual address range allocation to userspaceThere's currently a lot of code in the kernel dealing solely with managing user address space virtual address allocation. A more minimal kernel would only store the grants and their ranges, which would (1) allow userspace to implement gu...There's currently a lot of code in the kernel dealing solely with managing user address space virtual address allocation. A more minimal kernel would only store the grants and their ranges, which would (1) allow userspace to implement guard pages, (2) remove the need for `mmap_min`, and (3) simplify mmap and similar operations, so that they always behave as `MAP_FIXED_NOREPLACE`.https://gitlab.redox-os.org/redox-os/kernel/-/issues/133Orbital exits with "invalid argument"2023-08-04T06:13:34ZRon WilliamsOrbital exits with "invalid argument"On an HP laptop where Orbital previously worked, during boot, Orbital reports `orbital::core::display:48 failed to map display: invalid argument`, and Orbital exits. This appears to be an error code from `syscall::fmap`.
Display size wa...On an HP laptop where Orbital previously worked, during boot, Orbital reports `orbital::core::display:48 failed to map display: invalid argument`, and Orbital exits. This appears to be an error code from `syscall::fmap`.
Display size was `1366x768`. `1024x768` appears to work.
Edit: This is reproducible on QEMU, choose resolution 1600x900 and Orbital will exit with the same error.https://gitlab.redox-os.org/redox-os/kernel/-/issues/132Boot time scales inversely by the number of CPUs2023-07-13T14:25:48ZJacob Lorentzon4ldo2@protonmail.comBoot time scales inversely by the number of CPUsThis can be checked by comparing the boot time (context switch and syscall heavy), when setting QEMU's `-smp` to 1, 4, or 16.
The global context switch lock, combined with every processor being preempted exactly at the same time (the BS...This can be checked by comparing the boot time (context switch and syscall heavy), when setting QEMU's `-smp` to 1, 4, or 16.
The global context switch lock, combined with every processor being preempted exactly at the same time (the BSP sends out IPIs when there are PIT ticks), and that the context is locked numerous times for each syscall, might be the primary causes of this slowdown.https://gitlab.redox-os.org/redox-os/kernel/-/issues/131Support 32-bit userspace when using 64-bit kernels2023-07-08T09:22:45ZJacob Lorentzon4ldo2@protonmail.comSupport 32-bit userspace when using 64-bit kernelshttps://gitlab.redox-os.org/redox-os/kernel/-/issues/130 needs to be fixed, and there probably needs to be two permanent GDT entries, for FS and GS.
It might be possible to allow enabling/disabling compatibility mode, at compile time.https://gitlab.redox-os.org/redox-os/kernel/-/issues/130 needs to be fixed, and there probably needs to be two permanent GDT entries, for FS and GS.
It might be possible to allow enabling/disabling compatibility mode, at compile time.https://gitlab.redox-os.org/redox-os/kernel/-/issues/130x86 segment registers are not saved/restored2023-08-08T09:50:44ZJacob Lorentzon4ldo2@protonmail.comx86 segment registers are not saved/restoredOn x86, segment registers are currently not saved and restored when context switching. Since userspace is capable of loading available selector values into segment registers,
- CS is immutable, everything but GDT_USER_CODE #GPs
- SS (wi...On x86, segment registers are currently not saved and restored when context switching. Since userspace is capable of loading available selector values into segment registers,
- CS is immutable, everything but GDT_USER_CODE #GPs
- SS (will be) immutable, can only be set to GDT_USER_DATA
- DS, ES, FS, and GS, can be either NULL or GDT_USER_DATA,
at most four bits of data can be leaked between contexts when switching.https://gitlab.redox-os.org/redox-os/kernel/-/issues/129Support syscall62023-10-29T20:44:40ZJacob Lorentzon4ldo2@protonmail.comSupport syscall6Redox currently supports syscall0..=syscall5, i.e. rax+rdi+rsi+rdx+r10+r8, but some future syscalls like preadv2/pwritev2 (and futex?) on 32-bit architectures would need e.g. SYS_PWRITEV2+fd+addr+len+off_lo+off_hi+flags, i.e. 7 args.
Th...Redox currently supports syscall0..=syscall5, i.e. rax+rdi+rsi+rdx+r10+r8, but some future syscalls like preadv2/pwritev2 (and futex?) on 32-bit architectures would need e.g. SYS_PWRITEV2+fd+addr+len+off_lo+off_hi+flags, i.e. 7 args.
The registers Linux uses for that, are
- x86_64: rax, rdi, rsi, rdx, r10, r8, r9
- x86_32: eax, ebx, ecx, ecx, edi, esi, ebp
- aarch64: x8, x0, x1, x2, x3, x4, x5, x6
Might be worth looking into whether supporting full-width syscall return values, on x86/x86_64, by setting the carry flag, improves performance (the BSDs do this IIRC).