#uACPI - a portable and easy-to-integrate ACPI implementation
1 messages · Page 38 of 1
i don't really count those as direct usages
True
I guess I have enough fixes to publish a 1.0.1 tomorrow
Right now I simulate persistent io, aka all stuff thats written can be read back so I could do that actually, maybe I should
Previously it would just read FFs
More coverage = better so ig
qemu-system-x86_64 -accel kvm -cpu host,migratable=off -debugcon stdio -M q35,smm=off -cdrom proxima.iso | grep -E 'avg 1[1-9][0-9]{6,}' maybe i'm a little ambitious
uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10995672/s)
so fucking close
uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 11059937/s)
yep.
how much does performance differ if you don't pass ,smm=off?
@left orbit here's a cheaty one with magazines if you want to test later
Lol
pretty significantly since it page faults after the first one and the first one has cold caches, both cpu and allocator ones
i can try fixing the pf bug rq
Yeah just move the if statement
I wonder why there's an impact at all
could be placebo
could be that i ran it without smm thousands of times filtering for an 11M result and i only ran the with smm one like 5 times and took the highest
Yeah
it definitely feels like there's more results in the high 9M range
but idk
instead of the low 10M
still crazy that i'm getting low 9M on a leaderboard-legal build
Yeah idk how thats even possible
i really want to clean up the code and put it on git and the leaderboard as the last thing i'll do for the old kernel
Likewise lol
but to get a comparable iso i'd have to do some really weird shit with github actions and i'm not really up for that
well really weird is maybe an exaggeration, i'd just have to switch the commit the hydrogen submodule is pointing to so that it uses the last main commit and then change it back in the next one
but it still smells
Force push
you make a good point
Lol
idk if github actions will even work rn since the last run (a few hours ago) got a 502 from one of the deps' git servers
GitHub actions are so flakey
it's not really actions itself in this case, just gnu's git servers
Sometimes stuff just hangs too
i've never had that happen
Lucky
Or you don't do apple runners
oh yeah i don't
Those love to hang
i managed to fix {disable,enable}_preempt's performance problems and i'm still getting low 9M with cpu-local instead of thread-local so i think i will indeed be pushing this to git
I need to setup github actions for obos
like CI testing
considering how much obos regresses
it would be useful
yeah i've thought about doing automated testing for my kernel
but the way i want to do it requires a pretty large amount of userspace functionality so not yet
tbh idk how I'd do it
ah, the way i was thinking was to have a build option that makes the kernel shut down on panic (qemu has a way to do this with a single io port and you can also set qemu's exit code)
then just test syscalls with a 'normal' user program
and -no-reboot ofc
(launch qemu shit) | grep Arch_KernelMainBootstrap: Done early boot.
that doesn't seem like it needs a large amount of userspace functionality
the large amount of userspace functionality is mostly to have things to test
fair
I think half my syscalls are completely untested
as in, no userspace program uses them, and I never tested them manually
also wouldn't you need a cross compiler to compile a userspace program?
what I'll do is have a syscall to test all syscalls 
(don't ask how that would work, I just made something up)
I really gotta focus lol
gotta finish some homework for tomorrow
now i just have to wait 20 minutes and i can get the highest score proxima will ever get (because it's the last score i will submit before switching to a microkernel)
@fiery turtle new score for proxima, from CI image https://github.com/proxima-os/proxima/actions/runs/13103918229
uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10271084/s)
test cpu: Intel i7-13700k
here's the raw iso if anyone wants to test on their cpu
now that's more like it uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10054310/s) uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10235875/s) uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 9958414/s) uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10038682/s) uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10152858/s) uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10271084/s) uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10113532/s) uacpi: info: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10092639/s)
roughly the same as the cheating iso wtf
is that using the iso I just sent or one of the earlier ones I tagged you with
these logs are from the one right above
great, I can use them as my score
but the cheating iso gets the same results lol
what cpu?
i7-13700k
proxima finally works on intel :^)
and now my home directory is full of proxima isos
alright ty
np
finally an 8 digit score on the leaderboard
hell yeah
What the hell
i'm going to rewrite the pmm today, let's see what i can get out of it
do funny freelist
I can try compiling managarm in release mode with lto and such
I can also fix the remaining 5 assets that have side effects
because of birthday problem you now only have $$4K \cdot \sqrt{\frac{totalram}{4K}}$$ memory
david
--- a/source/uacpi.c
+++ b/source/uacpi.c
@@ -264,12 +264,16 @@ void uacpi_state_reset(void)
uacpi_deinitialize_events();
uacpi_deinitialize_notify();
uacpi_deinitialize_opregion();
- uacpi_deininitialize_registers();
- uacpi_deinitialize_tables();
#ifndef UACPI_REDUCED_HARDWARE
if (g_uacpi_rt_ctx.was_in_legacy_mode)
uacpi_leave_acpi_mode();
+#endif
+
+ uacpi_deininitialize_registers();
+ uacpi_deinitialize_tables();
+
+#ifndef UACPI_REDUCED_HARDWARE
if (g_uacpi_rt_ctx.global_lock_event)
uacpi_kernel_free_event(g_uacpi_rt_ctx.global_lock_event);
if (g_uacpi_rt_ctx.global_lock_spinlock)
@gentle peak is this how u fixed the pf?
@calm latch im updating the uacpi leaderboard, do u want to change your submission
managarm is down to 4th place
With which score?
u got like 8M yesterday
wtf u taking that one?
was it not legit?
god knows lmao
anyway im not unless mishakov submits it and its legal
This was consistent (?)
i think i got 7m after that or smth
current pmos score is 3M
I'm trying to implement fast IPC on x86_64 atm
yeah that one was more legit
(and having a skill issue with interrupts)
When will you be updating it?
right now
i'm happy to test :^)
if its only a few hours i can wait
yeah put pressure on him
lol
we need pmos fast ipc on x86_64
inb4 gets less

yes
fixed in a0fda56
big
huge
massive
lol
lmfao
ill publish 1.0.1 after the leaderboard update i think
and i should mention monkuous in release notes
for all the bug reports
I found the issue
Somehow pushw was not doing what I was expecting
just port your userspace to real mode
damn that is some old ass uacpi
time to update this shi to 1.0
im on edc5e219eb7ccefcfc8d0618018fabd51e83444f to be exact
tree from may 2024
iretq kernel revival 
Lol nice
So I guess uACPI must be fully working to get EC events?
[ 0.000000] [CPU0] debug(uacpi): uacpi_kernel_acquire_mutex: mtx=0xffffa00000017001
[ 0.000000] [CPU0] debug(uacpi): uacpi_kernel_acquire_mutex succeeded
[ 0.000000] [CPU0] debug(uacpi): uacpi_kernel_release_mutex: mtx=0xffffa00000017001
[ 0.000000] [CPU0] debug(uacpi): uacpi_kernel_release_mutex succeeded
[ 0.000000] [CPU0] debug(uacpi): uacpi_kernel_acquire_mutex: mtx=0xffffa00000017004
[ 0.000000] [CPU0] debug(uacpi): uacpi_kernel_acquire_mutex succeeded
[ 0.000000] [CPU0] debug(uacpi): uacpi_kernel_acquire_mutex: mtx=0xffffa00000017004```
what is uacpi cooking there
why is it acquiring the same mutex twice
hmm it happens in uacpi_install_address_space_handler_with_flags
ah so my thread id magically switched, good to know 
lol
i return 0 from both calls, hmm
why does your mutex have an alignment of 1 is also curious
lol
it's just an atomic boolean
thats like very early init
and this function is called one after another
like in a row
am i allowed to return 0 from get_thread_id?
yes
hmm
default thread_id_none is -1
well okay so im looking at uacpi_recursive_lock_acquire
and i see it checks the lock owner id
i return 0 twice, first presumably when it locks it the first time
and then the 2nd time it shouldn't acquire it again
well, at least not by calling the kernel api
oh that reminds me i might be able to remove some extra checks in my various mutex and thread calls since i no longer do uacpi init before i start up multithreading
btw, make sure your api is not using old signatures and stuff
mutex acquires now return a status
💀
yeah that was it lmao
new record [ 0.000000] [CPU0] info(uacpi): successfully loaded 1 AML blob, 1708 ops in 0ms (avg 1708000000000/s)
(apparently i init uacpi before time keeping
)
uacpi is faster than native cpu
compile your kernel to aml for free speed benefits
just wait for tomato's python to aml compiler
Did somebody already port managarm to post 1.0?
not bad
someday ill stop having irl things come up and fix my allocator crash so i can measure my zig kernel again
crashes with ReleaseSafe 
but not before showing me 10899947/s
idk how the fuck that happened but
¯_(ツ)_/¯
nice
kinda beat proxima, except my mutexes are stubbed
the panic call from all the asserts in gpa got merged to the same spot so my stack trace only tells me that an assert failed but not which smh
11050438/s pog
niiice
if you want to compare
i have a whole folder of these lmao
Wtf
9278911/s
idk 😭
the proxima intel curse continues
also mine isn't really no mutexes, it more like mutex = spinlock
yeah nw
apparently proxima-nomutex is slower than proxima with mutexes because i got the 10.27M result on iretq's cpu
it's just what your host is
you can set it on qemu's command line
-cpu host,migratable=off,tsc-frequency=1000000000 means tsc = nanoseconds
I have a different image...
yeah i was just asking about the tsc-frequency value
but if you don't pass that tsc-frequency flag it just uses whatever freq your host does
ah ok
the number of nanoseconds in a second
i was wondering lmao
thank fuck
10M with absolutely no optimization and not really stubbed mutexes would've been crazy
cuz if it was just that fast out of nowhere
yeah
but 1.1M sounds reasonable
especially with the slow as fuck zig GPA
definitely
nooo
I also do that
zeroing out all physical memory you allocate is slow tho
well its not really that slow
it's what you have to do when you give memory to userspace
like I tried to disable it on my kernel and the uacpi score didn't really change that much
for trusted processes you odnt have to
also dlmalloc expects it from mmap
have a page zeroing daemon and a flag in struct page
if the flag is set don't zero
I only zero pages given to userland
yeah but then you need to decide when to schedule that daemon, etc.
@calm latch i get the same score as with 32 bit pmos
IIRC there was a study at some point that concluded having a page zeroing daemon was actively detrimental to performance on modern CPUs.
last time i bumped uacpi it was still before 1.0
oh wow, i assume due to increased cache misses for other threads?
You're basically filling the cache with dead memory
BadgerOS just zeroes immediately before giving memory to userspace. The instructions to zero it out would be run anyway, so why do it in a way actively detrimental to performance?
I wonder what if you'd use non-temporal stores tho
i imagine you could still slightly optimize it by keeping the flag but not the daemon, but yeah
though ig it might still be better to just do that right when you allocate, idk
That requires to CPU to support them. I think that would probably make it better.
But I'm not sure how well those are actually supported by current CPUs.
yeah idk I just know that the instruction exists for eg. sse2
if it's in sse2 that's eh, because on one hand it's guaranteed present on any x86_64 cpu, on the other hand you need simd in kernel
oh?
movnti
ah yeah
I know that Linux doesn't actually immediately map pages for processes, only after the first time they access it. Perhaps that could be used to reduce the amount of pages actually zeroed and/or alloc'd at once.
i wonder how a page zero daemon with movnti would perform then
something i'll have to experiment with sometime ig
pretty sure that linux also has a shared zero page that's mapped on read fault
and then on write it gets CoW'd again for a freshly allocated page that you can write to
i know NT does that for sure
That's even less zeroing required ahead of time.
yeah, especially when you map a bunch of memory and read it but never write to it
doesn't that need tlb shootdown on the remap so that other cpus see the new phys addr?
like if one cpu writes to it, it gets remapped to a new page, and another cpu only ever reads from it
probably, idk lol
To know that you'd have to know how Linux makes its VMM thread-safe.
But probably yes
How many pages are read and not written shortly afterwards though?
Probably not that many but it's still less data flying around.
idk, when you have sparsely used data structures in userspace
Also, userspace regularly asks for way more memory than it actually needs for the heap.
Most of which would be just parked in this not-in-use state.
But then you (that's what I do) just allocate it on first access
But this just feels like unnecessary tlb shootdowns
Would you rather shoot down a TLB a couple times, or poison your caches with a daemon?
But one is not dependent on another
basically all code pages?
But you don't want them zeroed out
fair
they're also usually not anonymous
i wonder if using some cache maintenance instruction tricks to quickly zero out a page after allocating it would be faster than just memcpy
Having actually created caches (not professionally though) and understanding how they generally work, I don't think a TLB shootdown is really very bad as long as you're not blocking waiting for those shootdowns to finish at the other CPUs.
aarch64 has instructions to explicitly zero out cache lines for a VA for example
You kinda have to for POSIX (iiuic)
(block and wait that is, for stuff like mmap)
Remote shootdowns are a recent thing (?)
So instead of waiting, you start the process and simply switch to a different runnable thread.
By hardware
the shootdown means you can't switch to anything that shares page tables though
or that shared the shot page
but going from ro -> rw is less restrictive so you don't have to do a smp shootdown
But there's probably other processes that the CPU time can be spent productively on.
it's not the permissions being changed, it's the physical address being changed
in the pf handler you can just call invlpg if any other core accesses it
invlpg only invalidates the entry on the cpu that calls it
yeah but the tlb has either old page with ro or new page rw
Shouldn't be a problem if that page-that-is-always-0 doesn't ever move paddr. Which it doesn't.
cpu 1 reads from the page -> cpu 1 tlb is filled with the entry for the zero page -> cpu 0 writes to the page -> the ro page is cow'd to a different rw page -> cpu 1 doesn't see cpu 0's writes
Old page then would have stale contents
ah nvm
This is just an atomicity problem, if this breaks a process then it's that process' fault for accessing a page before the matching mmap in another thread returns.
when going from ro → rw, you don't have to invlpg unless you change the backing physical page, for example because of COW unsharing (which is quite common in this situation)
You could check the PTE in the page fault handler and invalpg if it's less restrictive than the fault implies.
yes i'm not disputing that
And that's what you get if you map shared anonymous zero page first
yea...
if you want total consistency, you essentially have to
- unmap the old page
- tlb shootdown the old page (yes, this must be done before step 3)
- map the new page
because of SMP races
static int *ptr;
static atomic_bool mapped;
static atomic_bool read_once;
static atomic_bool written;
// CPU 0
ptr = mmap(NULL, sizeof(int), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
atomic_store(&mapped, true);
while (!atomic_load(&read_once)) __builtin_ia32_pause();
*ptr = 5; // the read-only shared zero page gets changed to a read-write allocated page
atomic_store(&written, true);
// CPU 1
while (!atomic_load(&mapped)) __builtin_ia32_pause();
int i = *ptr; // put entry for read-only shared zero page in tlb
atomic_store(&read_once, true);
while (!atomic_load(&written)) __builtin_ia32_pause();
int j = *ptr;
assert(i != j); // this can fail if you don't shootdown!
No, I do unmap it first
Like I said, I wasn't suggesting to not shoot down, I was suggesting switching to a different process while shootdown eventually happens in the background.
ah i missed that
Wouldn't it be faster to just do it synchronously?
yes. imagine 3 CPUs:
- CPU1 writes to the page. This initiates the page fault, that maps the new page.
- However, before the TLB shootdown has completed, CPU2 stores something to the page, which doesn't fault since it wasn't in CPU2's TLB.
- CPU2 now does a release store to memory shared with CPU3.
- CPU3 does an acquire load, sees the release store from CPU2, and thus reads from the page. But it reads from the old COWed page, because it was in CPU3's TLB.
and thus, consistency is broken
often it's quite hard to make sure that the process you switch to shares the page though
(in response to a previous message)
.
Depends on how you actually go about doing the shootdown.
In that case I assume you'd be sending an interrupt to all other CPUs to do a shootdown and wait for them to respond.
its a relatively recent thing on x86 yeah, on other arches like aarch64 it has been a thing for a long time (armv8 has it)
that's what I do (more or less)
most modern x86 CPUs should support remote TLB shootdowns via invlpgb iirc
TLB shootdowns are a hard problem
that's amd only
Zen 3 and newer
Since we're talking about x86 paging, anyone mind helping me get that working? 😅
I have paging on RV64 working since forever but I can't seem to figure out what I'm doing wrong for x64.
It's the same, except you don't shift right by 2?
invlpgb doesn't exist on felixcloutier :L
there is a different thing for intel but I am not sure if its supported on any consumer cpus so far
like this?```
CPU1 CPU2 CPU3
read from page A, fill tlb
write, initiate cow
pte written, now page B
write to page B
read from page A
send shootdown ipi
that'd be a problem yeah
actually looks like it is likely supported starting at alderlake at least on the core series (which is really the only worthy series lol), its named Remote Action Request and its mentioned on all core datasheets >= alderlake
yes. note that there must be a release/acquire pair between CPU2 write and CPU3 read
must should, maybe it is implied
implied from the ordering yeah
it could potentially also be if the kernel uses a sequential shootdown (ie. first shootdown CPU2, then CPU3, etc..) that leaves two other CPUs in inconsistent states for a short period of time
... I don't think that a shootdown is needed when COWing if there's only a single other CPU
but whenever a third CPU comes along, that's when the problems start
here are TLB shootdown statistics on a 16-core 2 threads per core Linux system with an uptime of eight hours
(my host right now)
we are back on 4M
letsgo
new leaderboards
https://github.com/uACPI/uACPI/issues/114 Haiku maintainers just dropped
lol
lol
It's a
PR don't worry about it too much
if u move it to the bottom, change the message to Supports both 32-bit and 64-bit platforms and change the commit message to docs: advertise support for 32-bit *and* 64-bit ill merge it
lol sure
lmfao
done
forgot to add platforms at the end 
thanks lol
u removed fixes from the commit message btw
so it didnt auto close the issue
lol whoops
lol
even embed failed lmao
The image explains all you need to know XD

yeah like u can support i686, but not supporting pae is stupid
I can't think of a platform off the top of my head that doesn't need more than 32 bits of paddr in the maximum configuration.
RV32 has 34 paddr bits. x86 has PAE. ARM probably also has more than 32 bits there.
What's haiku even used for
Neither does RISC-V literally at all
I should do something cursed and make m68k acpi tables
acpi is little endian i think
or well, uacpi relies on little endian in some memcpies i know that for sure
All numeric values in ACPI-defined tables, blocks, and structures are always encoded in little endian format
the spec is basically worthless but it does say this
ah cool
i will not switch my aarch64 cpu into big endian mode and make an uacpi bug report that it doesn't work
i wonder if linux handles that
from what i've seen no
on linux iirc you need to change the kernel config for be aarch64
and for userland it's a separate target triple: aarch64be-linux-gnu
no like what im wondering is if acpica e.g. reads multibyte integers correctly if its configured for big endian targets
yeah no i understand
i'm just saying that it's a kernel kconfig option
which might force off the acpi option?
ACPICA has ACPI_BIG_ENDIAN
bruh wtf
couldnt they make it cleaner
ig thats one thing i should add to uacpi

although the only target for that would be aarch64-be
hm was itanium big endian?
im trying to figure out why acpica has be support in the first place
PDP endian support when? 
good question
wiki says selectable actually lol
Technically, RISC-V allows implementations to change endianness (of data only, not instruction) at any time with a single bit in mstatus
AFAIK basically all RISC-V cores are LE only
isn't there a byte swap instruction in one of the extensions?
support for be was added in like 2005
Yes
at least the commit is from that year
It will reverse the bytes in an integer register.
basically htonl()
It's a single instruction that does the endianness swap in htonl or nltoh, yes.
Actually it's ntohl. Whatever.
anyone with an aarch64-be kernel here so I could test if i add support for it at least lol
I mean I could probably add that just for the fun of it (well its actually kinda annoying and be is retarded
)
Cringe endian
yeah ngl its annoying af
id have to wrap everything
like all table fields accesses
Actually there's a GCC attribute for specifying a struct's endianness.
idk if its really worth tbh
there's a GCC attribute for everything
yeah idk
i support msvc as well
basically
MS tried the embrace, extend, extinguish once against GCC and is now allergic to adding anything beyond the C standard.
microsoft tried to kill everything good at least once
tbh i have some doubts about acpica support for big endian
i see it accesses table fields directly
like fadt.length etc
oh nvm
its not used by linux at all
❯ grep -rn ACPI_BIG_ENDIAN
drivers/acpi/acpica/acmacros.h:43:#ifdef ACPI_BIG_ENDIAN
OHHH
linux doesnt support ACPI on big endian aarch64
ok case closed then
im not adding it
Is that the only thing that selects ARCH_SUPPORTS_ACPI?
Maybe, idk.
ok so:
- x86 -> always LE
- ARM -> ACPI is never enabled
- ARM64 -> ACPI is only enabled if !BE
- loongarch -> always LE
- riscv -> no BE support(?) in linux
no other arch enables acpi
makes sense why this code bitrotted in acpica
Right.
I think it would be really cool if uACPI can get integrated into Linux (and maybe even mainlined because no ACPICA dev)
i think so too but
there's so many files calling into acpica directly
and they won't accept full-on switch without it being configurable probably
so you have to make an abstraction layer
That would be one refactor and a half
how many uses of acpica functions there actually are?
Oh well. At least you're completely dominant in hobby OSes 
lol
there are 817 files in there
i mean reactos is on their way, because nt architecture allows to easily replace it
haiku maybe
potentially bsds but less likely
did u count acpica files as well
because it lives in there
I dunno

that's lower than i thought it'd be
I'm certainly going to run the benchmark but what I'll do next depends entirely on score.
ah yeah, 301 in that case 
I'm not willing to make any changes that benefit the uACPI score but compromise the rest of the kernel though.
what is this?
So there won't be any mutexless BadgerOS builds
uacpi running on linux in userspace
i mean people did this just for fun lol
to see how much it bottlenecks it
did it for fun
lol
i mean that too but i was referencing the uacpi on linux in userspace thing
how did you do it?
daamn lol
is this LTO + O3 + AVX?
oh and for rsdp i did the "search every 16 byte boundary in ebda and bios rom" thing
yeah that should work
it's LTO+O3+SIMD, but x86-64-v1
ah
just default compiler opts
probably not because it's pretty shitty
damn
doesn't use libc, just raw inline asm syscalls
I always die inside a little when someone says this
for some reason mknod("/dev/mem", 0600, 0x101) failed with EEXIST but open("/dev/mem", O_RDWR | O_SYNC | O_NOFOLLOW) failed with ENOENT so i had to improvise and put things in /dev/laijfjga/mem
did you do it to have some reference points to compare against your future microkernel?
i yoinked the allocator from proxima and stubbed all the locks so it can't be that
Is Linux intervening in the memory accesses maybe?
if you mean that linux's own acpi stuff is intervening, def not since i compiled this kernel with CONFIG_ACPI=0
No I mean /dev/mem access in general.
dev mem should just map those pages on fault probably
maybe it's this
depends on how it's implemented
Elixir Cross Referencer - source code of Linux v6.13.1: arch/x86/mm/pat/memtype.c
disabled it and it's the exact same perf
/* Remap-pfn-range will mark the range VM_IO */
this sounds like it might be the problem
No cache?
i also don't override libc but given that uacpi's builtin memcpy/memset beats the phd memcpy/memset when lto is involved that shouldn't be the issue
decided to publish it anyway https://github.com/monkuous/uacpi-linux
if you want to sure but i don't really see the point
most of the code is just like 200 lines of { STUB(); }
Well idk, but very interesting project nonetheless
now that i'm getting back into zig i should work on proper zig bindings

pmOS does that and it's not that bad
i could actually use my profiler on this since i have iopl for debugcon
yknow i just realized the bad perf might also be because i'm running this off of qemu vvfat
i should do the funny rerun it ten times thing
nope the later runs get 1.5M

im glad i'm off that shit
it's useful if you don't have the patience to set up proper build stuff
i'm looking at this profiler data and there aren't any major smoking guns i can see
it all just seems like.. general slowness
i filtered it to just kernel api calls and the things they call and everything except map/unmap is faster than proxima
map/unmap are both only called once and in total contribute 8.5 microseconds, so that can't be it
it might really just be that linux maps stuff as uncacheable
I'm surprised that there aren't any ioctls or anything like that to request a different cache mode (although ioctls wouldn't map well to this)
oh nevermind it was a me skill issue
i removed O_SYNC from open("/dev/mem")
now it's 10M/s
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 5671913/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10093714/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10832549/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10885943/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 9726239/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10588615/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10722730/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10740969/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 9956146/s)
uacpi[3] successfully loaded 1 AML blob, 1705 ops in 0ms (avg 10806459/s)``` 10 iterations
so does O_SYNC affect the cache mode of mmap on devmem?
like... why?
ohh shit... I map memory as UC- in uacpi_kernel_map_memory
is that why I get so bad results lol?
(todo: test tomorrow)
probably LOL
on x86 you can get away with unconditional WB because of the MTRRs
on other arches you're supposed to scan the memory map
because probably AMD and Intel handle things differently with the caching mode the guest specifies
smh my head...
I still get like 2.3M on my AMD CPU though... which is slightly less than double this
well this was the only thing i changed to fix it
so unless linux does more special stuff with O_SYNC /dev/mem, i don't know what else it could be
also keep in mind that that's the first run from an executable that's being demand-paged from qemu vvfat
ahh
that has a significant impact on performance
like here, the first run is twice as slow as the 2nd
and also different CPUs
damn. I really should implement the re-run it 10 times meme
it has a less significant impact in an actual kernel because there's no demand paging
but it helps yeah
you could also just mlockall ();
L1d/L1i memes? or branch predictor memes?
who knows
just turn off the branch predictor and look only at L1d/L1i

feel free to steal my imaginarium ones as a starting point
with -march=native -mtune=native (and without mlockall) i get 6.3M on my first run and consistent 11.5M on further runs
do you do SSE/AVX/whatever cool things the CPU supports?
i mean this is a linux usermode binary so yeah
do you do it in your record-holding kernel too?
i'm just compiling with -O3 -flto -ffreestanding -fno-stack-protector
no, that'd be cheating
i do have a build which does so
but that's not the one on the leaderboard
I 'only' use -O2 (because -O3 code is just fkin ugly)
further on this point, my uacpi bindings in imaginarium were always originally meant to be a standalone uacpi zig bindings library but working a second layer of shims became more annoying than I wanted to deal with
might revisit that though
(tbh I kept getting tempted to do a full-scale port of uacpi to zig instead of just idiomatic bindings lmao)
diff --git a/acpi/osl.c b/acpi/osl.c
index 37abdfa..8fe8cae 100644
--- a/acpi/osl.c
+++ b/acpi/osl.c
@@ -187,7 +187,7 @@ void *
uacpi_kernel_map (uacpi_phys_addr addr, uacpi_size len)
{
return vmap_phys ("uacpi_kernel_map", addr, len,
- PAGE_KERNEL_DATA | PG_UC_MINUS);
+ PAGE_KERNEL_DATA);
}
void
[ 0.111543] uACPI: successfully loaded 1 AML blob, 1702 ops in 0ms (avg 4393516/s)
before this patch: [ 0.112889] uACPI: successfully loaded 1 AML blob, 1702 ops in 1ms (avg 872106/s)
870k wtf
I will probably not do this immediately. I'm cooking up some stuff for keeping track of attributes of physical memory regions
though it is interesting to know
my kernel is having severe AMD skill issues lol
I hope to atleast somewhat match the i7-13700K in terms of performance (~6.3M) on my CPU if I fix the caching mode stuff
you have a 7950X right? if so you probably will
X3D
so half the CPU cores are weird
:p
I just re-run it a bunch of times and filter out the outliers
yeah? where does the spec say that?
or are you just relying on Linux and hearsay?
exactly
"the memory map" aka the EFI memory map
what if you're not even using that
you can have ACPI without UEFI
linux and hearsay
"you're supposed to" doesn't always mean there's a spec that says you should. in this case the ACPI spec says absolutely nothing about it, so the best you can do is scanning the memory map
as for situations where you don't have a memory map, if you can know the ranges of memory your pmm is allowed to manage you have enough information for the memory map scanning
hearsay is how most of acpi works
I also map all physical memory ad UC 
who knows
you would never know
if it didnt log
how often does it spam
looks like it drops roughly 1000 per notify
so probably expected idk
every ~300ms
yeah probably fine
id suspect a storm if there was an aml error in the logs, but this looks fine
but can always compile linux with printfs and see if it gets this as well
Submit it to move obos up the leaderboard
nahhhhh
I gotta get over 1mil
I dont understand how my slab got slower when I added cpu caches
💀
lmaooo
Check pinned messages
I think my vmm code is at fault
If I had to guess
with this patch my kernel gets either somewhere around 4.5M or somewhere around 4.9M on my CPU.
@fiery turtle How do I use that mode with reading ACPI tables but without interpreting AML?
uacpi_setup_early_table_access iirc
uacpi setup early table access
Or smth
Don't call any other uacpi init functions
early table access is guaranteed to only call log, map, and unmap

YOOOOOO
FOSDEM shilling worked 
WE SHILLED uACPI AT FOSDEM

uACPI is just being based (as usual)
amazing lol
i also shilled Limine to them but there ain't no way they are moving to that :^)
i did install the haiku Limine package on the demo laptop they had at their stand though so there's that
(actually electrode did because i had no idea how to use the haiku pkg manager lol)
just read the issue that comment was in
you have above average social skills for a foss maintainer
With how many times I have falsely reported a uacpi bug to infy when it was obos' fault, I agree
all you did was be polite but i was literally expecting you to say something snarky like "excuse me? did you even read the code? of course there's 32 bit support. and even if there wasn't, send a patch instead of wasting my time with begging"
I have reported many uacpi bugs in my time using it
(I only found two real bugs)
most foss guys seem to have the like rice-grain of power go to their heads instantly
Finally integrating uACPI into BadgerOS and...
I honestly expected a #PF, not a #GP, if it was going to crash.
As usual, relevant GH link for anyone interested:
https://github.com/badgeteam/BadgerOS/blob/amd64/kernel/port/generic/src/uacpi_kernel_api.c
Look at r10 
That address is the least canonical address I have seen for a while
That be look like an ASCII

Wait is that a dwarf parser in-kernel
For the stack trace
No it's just walking the stack frames left by the function calls
What about the line numbers??
This goes through an external filter that runs addr2line
It's very elegant for not having to actually parse the DWARF info while still having a useful backtrace
yeah its a sick tool
i need to get around to that for mine
though half the time my stack traces are off
(my stack walker is giving me return addresses so its always like off by an instruction i find)
Uhhhhh did I mess up my MMU code again or something?
If an address was going to not be canonical, it would be 0xffff000000001500 right?
I think that I made mmu_half_size twice as much as it should have been...
whats the actual instruction from a disassembly at that RIP address?
If bits 48-63 don't match bit 47 of the address
Or smth
gp fault can be many things
yep
the address has to be sign-extended from the max width of whatever your paging setup is
but depending on instruction idk if R10 being not a canonical address matters
R10 is not involved.
could be a packed int of stuff
I checked the asm
Show
yeah exactly
That shit is not canonical
I missed that in your register dump
yep
Because 8 kinda looks like 0 in that font
i just cant read lol
Lul
Also your name kinda reminds me of a word in arabic
Display name
neat! tis derived from the name of a character from a book i like but with an h added to fit the naming conventions for characters of a certain species in an mmo i used to play when younger lol
lol
Anyway I go slep
The word I am thinking of means something like "good"
But it's a bit hard to translate
mhm
oh lol every once in a while i remember that someone managed to snipe issue #6502 for giving zig a 6502 compiler backend
Lol
i.e., it's more descriptive than just the word 'good'
ye
im stupid, the zig stack trace printer just subtracts 1 from every return address before printing lmao, i forgot to add the same to my print code
Is uacpi_kernel_io_map the one that expects to use x86 I/O ports (e.g. inb/outb)?
yep
most kernels implement it by just treating the out as a *u16 instead of a **void and passing the base directly through
And that's what I just did too

Unfortunately I still have some broken timekeeping so I don't know how long this actually took to run.
And now I am going the fuck to sleep

Lol ty
Letsgo!
is that really such a low bar?
nice
Go to https://surfshark.com/totallynormal for 4 extra months of Surfshark at an unbeatable price!
We finally have the Firefox web browser back on Haiku! Let's install it and see how well it works.
⭐️ I auction old tech from my videos on Whatnot! https://whatnot.pxf.io/retro
⭐️ I use Bambu 3D printers https://bit.ly/bambu3D
LINKS:
------------...
apparently they ported firefox
damn
managram when
What did you guys even say lol
uACPI clearly superior, ACPICA kinda (maybe temporarily) unmaintained and sometimes weird/incorrect behavior
When Firefox doesn’t suck ass and systemd and old Xorg get priority now
Also I’ll be doing some ironclad work soonish (I know, shocking) but it’s a good project and my assistance has been requested (well, more like asked info wanted to do that but whatever)
Year of the managarm desktop before Linux desktop??
Potentially. It depends. Xorg might not need to happen if systemd works and that solves my KDE issues
GNOME is a different beast, but I might’ve just discovered a funny I can do to debug that
i really wonder what's the story with him
we all know what happened and for a time it looked like he had gone, then for a while longer like intel had quietly held onto him
Maybe Intel forgot to remove repo access 
LETS FUCKING GO I HOPE THAT'S THE GUY I SHILLED IT TO
@fiery turtle
[00001.342] INFO successfully loaded 1 AML blob, 573 ops in 15ms (avg 36780/s)
I suck at this game 
On an AMD Ryzen 5 3600
Oh wait that's not with -M q35 hang on
[00000.054] INFO successfully loaded 1 AML blob, 1705 ops in 1ms (avg 1018518/s)
Still not good lol
Close to obos
not terrible either at least
Does anyone else have an ISO so I can compare on the same host CPU?
Or send your ISO here
qemu-system-x86_64 -M q35,smm=off -accel kvm -drive format=raw,file=path/to/image.hdd -debugcon stdio -display none
I wonder if there's a way to profile this stuff.
pinned
Yeah pinned messages has a nice profiling tool by monkuous
with your command line: 800k
with -cpu host: 1.2M
5800X
if i made a microkernel, should i make uacpi run in kernel or in user mode
Oh yeah chaning that to -cpu host made it 900K for me instead of the old 650K
user mode imo, although that makes sleeping much more complicated
But proxima still does like 5M on my machine
any pointers as to how to expose rsdp to user mode?
Sometimes the answer is in the question 
i don't really want to have a syscall dedicated to do that
I just give user mode something similar to mb2 boot info + some handles and let it figure out the rest
as in it's state that's passed to init
/Dev/mem
you can make it a handle to the phys mem region and then have a syscall that allows mapping a memory handle
See monkuous uacpi userspace linux port
or something like that
fair
So f.ex init on startup would get a handle to a memory object that lets you map any physical memory, and the info structure init gets also contains the physical address of RSDP
@gentle peak where header file
Wdym
i'm rewriting parts of it because i don't want to be that one gif electrode made
You only have the src for the profiler
i also want to experiment with distributed systems potentially
I see
What is I map all memory as normal? 
wdym
that destroys perf on amd
Like on x86 MTRR should handle that anyway (?)
linux-uacpi went from 1.2M to 10M when i stopped mapping everything as UC
if you map everything as WB, MTRR will take care of things
if you map everything as UC, it'll override MTRR
yeah for that your best bet is checking whether the memory is allocatable
ehh
not really
risc-v has PMA which is supposed to take care of that
in reality that's not how things work
for example, iirc on some chipsets you add a specific offset to the physical address to indicate cache mode

okay so with uACPI being in user mode, what's the best way to handle timers on x86_64 and aarch64?
have a table parser in kernel mode
table parsing in kernel mode is basically required for timers on any modern acpi-based platform
Wdym timers? Don't you just have sleep syscall?
?
Oh you mean the source for the kernel lol
luckily, table parsing is incredibly easy and the full thing can be done in <200 lines
have uacpi in both kernel and user mode 
Rdtsc + acpi timer 
microkernel
uACPI in kernel with only table stuff in barebone mode (or use lto until barebone mode is ready) and full uacpi in userspace
then i need to restructure my submodules lol
i don't really see the point of using uacpi if you only need table parsing
i mean i don't
even in the future barebones mode
i mean yes, that's what i did before
My kernel only uses LAPIC + TSC (from recently)
my pc has pit
How do you calibrate em?
Since RISC-V doesn't have global timers
ok then maybe someone else's
someone here had a PC without PIT
my kernel can use hpet, KVM timer, and TSC
I plan on redoing the timer subsystem, and supporting everything
LAPIC, (deadline) TSC, PIT, HPET and ACPI
And also make kernel preemtable by timers
just published the 1.0.1 release
neat
@fiery turtle ```[INFO:UACPI] successfully loaded 1 AML blob, 1720 ops in 0ms (avg 1737654/s)
Can you add this one to the leaderboard too? (even though it sucks lol)
Ryzen 5 3600
Ig for description the best I can think of is Hybrid Unix-like kernel
lmao
aint nothing special about it
No hurry im just queuing the changes for now
A monolithic lightweight UNIX clone
You can edit the message later
Lmfao
OSDev in a shellnut
There was one of these gifs that said monolithic Unix like kernel with limine or something like that
@severe swift
^
💀
osdev starter kit
Lol
shilling my vids 
yessir

@fiery turtle Mutexes have fast path now, speed is now at 1.0M ops/s
[00000.054] INFO successfully loaded 1 AML blob, 1705 ops in 1ms (avg 1018518/s)
@severe swift osdev slander 2 when
I mean there is the low effort OSDev slander 1.5 which is pinned in memes I think
I was gonna make another one at some point soon tho because I think we have enough meme material for one again
Can you edit the old message pls?
Here is my attept to use uACPI in Haiku so far: https://review.haiku-os.org/c/haiku/+/8937 Questions: I didn't find an equivalent to AcpiFindRootPointer from ACPICA (this searches the ACPI entr...
damn
haiku maintainers are fast
