plarke has quit [Remote host closed the connection]
heat has joined #osdev
<heat>
mjg, ok, so I have some theories
<heat>
1) storing is working like a weird sfence; i tried adding explicit sfences but they had 0 impact on perf (what does this mean? I've never measured sfences in a normal setting)
GreaseMonkey has quit [Quit: No Ping reply in 180 seconds.]
<heat>
2) aligning may be slower than just fuckin copying. unlikely. glibc also aligns, but with vector-sized stores ofc
<heat>
3) something funkay is going on. I don't know how to interpret intel PT's results
<heat>
4) maybe it's just not worth it for kabylake
<heat>
also: why tf are you not enabling erms in your stringops its 2023
pmaz has quit [Quit: Konversation terminated!]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 260 seconds]
linear_cannon has quit [Remote host closed the connection]
bauen1 has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
grange_c0 has joined #osdev
Terlisimo has quit [Quit: Connection reset by beer]
frkazoid333 has quit [Ping timeout: 240 seconds]
bauen1 has quit [Ping timeout: 276 seconds]
bauen1 has joined #osdev
Terlisimo has joined #osdev
dayimproper has joined #osdev
<mjg>
heat: i have negative brianpower this week
<mjg>
heat: prod me monday
<gog>
mood
<sham1>
doom
dayimproper has quit [Ping timeout: 268 seconds]
<zid>
doog
<sbalmos>
Morbo? dooooom
<gog>
it's morbin time
<GeDaMo>
The times, they are a-Morbin'
<gog>
i've got the morbs
<bnchs>
aaaaaaaaa
<bnchs>
morbin
[itchyjunk] has joined #osdev
[_] has joined #osdev
[_] has quit [Remote host closed the connection]
dude12312414 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
dayimproper has joined #osdev
CryptoDavid has joined #osdev
dude12312414 has joined #osdev
FreeFull has joined #osdev
<heat>
morb be gog
<gog>
angel of the morbin
<heat>
gog u are gorg
<netbsduser```>
just experimented with chatgpt as youth are wont to do
<heat>
or better, morg
<netbsduser```>
i hoped it would help me writing a new namei that isn't incomprehensible and unmaintainable like my current one
<heat>
no.
<heat>
i tried making it explain how to read an ext4 inode, or making it explain how a maple tree works, would be an idea
<heat>
but it doesn't work
<heat>
chatgpt and the c stands for crap
<netbsduser```>
what it made was mostly unusable, i never saw anything quite so wanton and ghastly, terrible
theboringkid has joined #osdev
<heat>
yes
<netbsduser```>
it did do a reasonable job at splitting up a pathname by / delimiters but that's really not what i wanted it to help me with
<heat>
anyway if you want a good namei you better look at what's wrong with yours atm, plus what's wrong with others
xenos1984 has quit [Ping timeout: 260 seconds]
<netbsduser```>
what was wrong with mine was that it was thrown together ad-hoc and turned into a mess when it gained support for things like lookup-to-the-2nd-last-component
<netbsduser```>
also it was recursive when there were symlinks
<netbsduser```>
and for a reason i never figured out, reasoning instead i'd be better off rewriting it, it didn't refcount vnodes properly. the new one is much nicer
<netbsduser```>
i am just putting the finishing touches on it
<bslsk05>
github.com: Onyx/namei.c at master · heatd/Onyx · GitHub
xenos1984 has joined #osdev
<netbsduser```>
heat: this might be the test suite i was looking for all my life
<netbsduser```>
or at least since i wanted to rewrite namei(), and as the saying goes, life begins when you rewrite namei()
<heat>
haha yes
<heat>
linux refactored some nice bits of their namei back in 2020 and accidentally broke some obscure behavior (the O_DIRECTORY | O_CREAT thing). this found it
<heat>
doing refactoring of namei without any sort of testsuite is madness
<heat>
if you think of any improvements feel free to send a PR
slidercrank has quit [Ping timeout: 256 seconds]
goliath has quit [Quit: SIGSEGV]
dayimproper has quit [Ping timeout: 268 seconds]
<sham1>
Doing any refactoring without tests is madness and broken
<sham1>
If you're not doing TDD, you're doing it wrong
theboringkid has quit [Quit: Bye]
<gog>
we are absolutely doing it wrong
gog has quit [Quit: Konversation terminated!]
<Ermine>
gog: may I pet you
<puck>
how can you pet someone who isn't there,
<heat>
whos gog
<heat>
never heard
<Ermine>
remote procedure call
xenos1984 has quit [Ping timeout: 246 seconds]
<sham1>
Better be asynchronous
<heat>
AWAIT
<zid>
yield_to_mommy_sched();
nvmd has joined #osdev
heat_ has joined #osdev
nvmd has quit [Quit: WeeChat 3.8]
heat has quit [Read error: Connection reset by peer]
heat_ is now known as heat
nvmd has joined #osdev
xenos1984 has joined #osdev
frkzoid has joined #osdev
goliath has joined #osdev
elastic_dog has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
elastic_dog has joined #osdev
slidercrank has joined #osdev
heat has quit [Remote host closed the connection]
heat_ has joined #osdev
<mrvn>
Anyone have a per process/thread namei cache?
<mrvn>
like store the 2nd-last dir of the path walk in the thread in case they will open a file in the same dir again.
heat_ has quit [Remote host closed the connection]
heat__ has joined #osdev
bauen1 has quit [Ping timeout: 256 seconds]
lanodan has joined #osdev
heat__ is now known as heat
heat is now known as mild-warmth
mild-warmth is now known as heat
slidercrank has quit [Read error: Connection reset by peer]
slidercrank has joined #osdev
slidercrank has quit [Remote host closed the connection]
slidercrank has joined #osdev
linear_cannon has joined #osdev
<heat>
does anyone know how fast qemu kvmclock updates?
dude12312414 has joined #osdev
bauen1 has joined #osdev
goliath has quit [Quit: SIGSEGV]
slidercrank has quit [Ping timeout: 256 seconds]
CryptoDavid has quit [Quit: Connection closed for inactivity]
<puck>
heat: do you trust the TSC?
<heat>
yes
<puck>
okay so the kvmclock structure only updates when you write the MSR
<heat>
hm?
<heat>
oh. i had not realized that
<puck>
ah, system_time_new does auto-update randomly
<heat>
so where's the win? I still vmexit
<heat>
ah yes, that must've been what I read
<puck>
to be precise, whenever timekeeping_update is called, i think
<heat>
like, erm, the TSC is fine here, but it vmexits, which I would like to avoid
<heat>
having a memory mapped clock here is ideal, but I don't know its accuracy
<puck>
heat: are you sure rdtsc vmexits?
<heat>
yep
<puck>
how old is your cpu? :p
<heat>
kbl
<heat>
maybe I fucked up the qemu flags, but a quick CLOCK_REALTIME bench under the vm showed it slowed down a whole lot vs on the host
<puck>
both intel and amd have virtualisation extensions to do TSC offsetting
<heat>
i know, but does qemu leverage it?
<puck>
it's a kvm thing
<puck>
looks like linux can't even handle EXIT_REASON_RDTSC natively?
<puck>
heat: like, i think you might want to test if your VM even has the rdtsc feature turned on
heat has quit [Ping timeout: 240 seconds]
heat_ has joined #osdev
terminalpusher has joined #osdev
<heat_>
i do have rdtsc plus invtsc
<heat_>
(you need to force invtsc in qemu's cmdline)
<heat_>
i am fairly sure it is vmexiting but I'll re-test in a bit once I get a setup
jimbzy has quit [Ping timeout: 248 seconds]
<puck>
it'd be fun to see the vmexit reason
jimbzy has joined #osdev
<puck>
probably try running `perf kvm stat live -a`
heat__ has joined #osdev
heat_ has quit [Read error: Connection reset by peer]
heat__ has quit [Remote host closed the connection]
heat_ has joined #osdev
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<heat_>
puck, perf kvm stat live -a doesn't work
<heat_>
:(
<puck>
heat_: ...are you kvming???
<heat_>
yes, the command doesn't make sense
<heat_>
I get Usage: perf kvm [<options>] {top|record|report|diff|buildid-list|stat} ....
<heat_>
also fwiw my perf kvm record has been permanently broken
<heat_>
hell, doing it right now is making guest /sbin/init die
<heat_>
all this tooling is so broken it's not even funny
heat_ is now known as heat
<puck>
heat: for me:
<puck>
Usage: perf kvm stat live [<options>]
<puck>
-a, --all-cpus system-wide collection from all CPUs
<puck>
and i tested it out, it does show up a qemu i'm running in another terminal
<heat>
yeah that does not work
<heat>
(here)
<heat>
perf version 6.2.gc9c3395d5e3d
<puck>
6.1.26
<puck>
like, does it just not load into the "analyze events" screen?
<puck>
"Unlike the RDTSC instruction, RDTSCP forces all older instructions to retire before reading the timestamp counter" but no mention of the lfence-like behavior
<puck>
to be fair, i'm not sure i need to do a million rdtscps a second, so eh
<heat>
if you're tracing you might
zid has quit [Remote host closed the connection]
zid has joined #osdev
biblio has joined #osdev
eschaton has quit [Remote host closed the connection]
zid has quit [Ping timeout: 240 seconds]
zid has joined #osdev
goliath has quit [Quit: SIGSEGV]
linearcannon has joined #osdev
linear_cannon has quit [Ping timeout: 250 seconds]
Burgundy has quit [Ping timeout: 268 seconds]
Turn_Left has quit [Read error: Connection reset by peer]