froggey has quit [Remote host closed the connection]
Reinhilde has quit [Ping timeout: 268 seconds]
maksy_ has quit [Ping timeout: 268 seconds]
maksy_ has joined #osdev
Ellenor has joined #osdev
ElementW_ has joined #osdev
Irvise_ has quit [Ping timeout: 268 seconds]
ElementW has quit [Ping timeout: 268 seconds]
zaquest has quit [Remote host closed the connection]
aejsmith has quit [Ping timeout: 250 seconds]
aejsmith has joined #osdev
froggey has joined #osdev
manawyrm has joined #osdev
zaquest has joined #osdev
Jari-- has quit [Remote host closed the connection]
nyah has quit [Quit: leaving]
Burgundy has quit [Ping timeout: 240 seconds]
Irvise_ has joined #osdev
JanC has quit [Ping timeout: 240 seconds]
JanC has joined #osdev
biblio has quit [Quit: Leaving]
puck has quit [Remote host closed the connection]
phr3ak has quit [Ping timeout: 268 seconds]
puck has joined #osdev
JudgeChicken has joined #osdev
phr3ak has joined #osdev
ZombieChicken has quit [Ping timeout: 276 seconds]
Oli has joined #osdev
Ellenor is now known as Reinhilde
JudgeChicken has quit [Remote host closed the connection]
JudgeChicken has joined #osdev
superleaf1995 has quit [Quit: Leaving]
Oli has quit [Quit: leaving]
heat has quit [Remote host closed the connection]
heat has joined #osdev
orthoplex64 has quit [Remote host closed the connection]
orthoplex64 has joined #osdev
<geist>
gosh after all this work to set up data transfers on AHCI looks like nvme is going to be EZ TIME
<geist>
it's like ahci gives you most of the tools to build something really efficient, and then just pulls back at the last minute and makes you grub around to figure out how to handle things well. especially NCQ
JudgeChicken has quit [Quit: WeeChat 3.4]
ornxka has quit [Ping timeout: 256 seconds]
ornxka has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
scoobydoo has quit [Ping timeout: 240 seconds]
ornxka has quit [Remote host closed the connection]
ornxka has joined #osdev
tenshi has quit [Ping timeout: 240 seconds]
srjek has quit [Ping timeout: 240 seconds]
sdfgsdfg has joined #osdev
sdfgsdfg has quit [Client Quit]
xenos1984 has quit [Read error: Connection reset by peer]
scoobydoo has joined #osdev
xenos1984 has joined #osdev
tenshi has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
j00ru has quit [Ping timeout: 240 seconds]
j00ru has joined #osdev
Mutabah has quit [Ping timeout: 256 seconds]
smeso has quit [Quit: smeso]
sonny has joined #osdev
smeso has joined #osdev
sdfgsdfg has joined #osdev
sonny has left #osdev [Closing Window]
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
Burgundy has joined #osdev
Burgundy has quit [Ping timeout: 268 seconds]
Jari-- has joined #osdev
<Jari-->
Guys what do you think on business long-term goal, is Open Source or Propertiary Operating System better ? To get money.
ElectronApps has joined #osdev
nanovad has quit [Ping timeout: 240 seconds]
nanovad has joined #osdev
vdamewood has quit [Quit: Life beckons]
Mutabah has joined #osdev
ElectronApps has quit [Remote host closed the connection]
tenshi has quit [Quit: WeeChat 3.4]
<kazinsal>
neither, this is a shit thing to make a business out of
<kazinsal>
unless you're doing something extremely specific and niche like high performance routing or storage and your sole focus is on that and you REALLY know what you're doing
<kazinsal>
and I don't mean on paper know what you're doing and "run it through the optimizer" high performance
<kazinsal>
I mean this particular microsubject is your actual honest to god getting paid for it field already
<kazinsal>
you would need to be a subject matter expert in that particular field and then some
<kazinsal>
AND be a good enough programmer with enough time to make something useful
<kazinsal>
AND have the connections to build a working hardware product
<kazinsal>
AND have the connections to market it successfully
<kazinsal>
basically, don't even think about it. it's not going to happen.
<klange>
I moved my old album of historic screenshots from Imgur to a GitHub gist and expanded it; I found a number of old screenshots in a laptop backup and have added new ones since the album was last updated long before 2.0
<bslsk05>
gist.github.com: 11 Years of ToaruOS · GitHub
Jari-- has quit [Ping timeout: 240 seconds]
<mlombard>
klange, this is amazing
ElectronApps has joined #osdev
Jari-- has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
heat has quit [Ping timeout: 250 seconds]
<geist>
everything kazinsal said
<geist>
it's exceptionally *exceptionally* rare to make money writing an OS nowadays
Jari-- has quit [Ping timeout: 240 seconds]
<kazinsal>
geist: update on the forum thread I mentioned the other day; they wanted to hear more baffling x86/PC architecture stuff so I just wrote a giant post about interrupt routing with a big terrifying middle section about ACPI bytecode haha
<kazinsal>
of course that's then followed with "thank god for PCI-SIG going 'no that's insane stop that' and giving us message signalled interrupts"
<sham1>
Who thought that the ACPI bytecode was a good idea
<geist>
i think there was a period of time when multi arch was a bigger deal (think intel trying to get people to switch to itanium and MSFT running on 3 or 4 arches) and no one had really thought that running arbitrary bytecode in kernels was going to be a security problem
<geist>
it's certainly not the first time bytecode interpreted driver and low level logic was used
<sham1>
One of the biggest annoyances is that one has to pretend to be Microsoft to do anything
<geist>
yah functionally speaking ACPI is the MSFT driver model. it's designed such that it basically drives the whole setup of what driver goes where
<geist>
hence why it's mandatory on ARM devices that windows runs on. they dont have a mechanism to convert device-tree/etc to their model
<geist>
or at least it would be some hard coded acpi thing
<kazinsal>
it first showed up around the time that high end workstations were shipping with Pentium Pros, PowerPC 604s, Alpha 21164s, or MIPS R4Ks so having some platform independent bytecode for figuring out how to handle interrupts and such for any arbitrary PCI card you slammed in there was handy
<kazinsal>
I wasn't there at the time but I suspect that in practice other platforms had much less dodgy interrupt controller setups than Intel did
<sham1>
Still, having to essentially lie to the bytecode "Hey, I'm actually Windows 2000" or whatever is weird
<geist>
i wonder if cpus feel pain when they have to run one kernel or the other
<geist>
like 'oh no not again'
<kazinsal>
"ugh, they're loading up TSS/360 *again*?"
<klange>
"this asshole keeps trying to run his garbage toy OS, please just kill me"
<klange>
i'm sure that's what my thinkpad thinks all the time
<kazinsal>
AS/400 machines waking up and lamenting that they've been pulled from spending time with their loved ones in the computer afterlife to go run some queries on a financial database from 1989
<kazinsal>
ha, after looking it up, I hadn't realized that the pre-POWER AS/400s ran on a 48-bit ISA
<geist>
hmm like 48 bit regsters or that was the virtual memory size?
<CompanionCube>
kazinsal: i wonder what the feeling of migration to modern POWER would be in that context
<kazinsal>
48-bit virtual and physical address space, 32-bit machine word
<CompanionCube>
do we actually know about the registers of the CISC ISA?
<kazinsal>
for AS/400? looks like 16 general purpose registers, a condition register, and a program counter
<kazinsal>
48 bit registers, 32-bit adder
<CompanionCube>
for pre-power 400 yeah
<kazinsal>
s/adder/ALU/
<kazinsal>
IEEE 754 double-float, doesn't say if there are registers for them or what
<CompanionCube>
(System/38 has rather more comprehensive documentation iirc)
<kazinsal>
yeah, I'm looking at an excerpt from a 1989 edition of the IBM Systems Journal that details some of it
bauen1 has quit [Ping timeout: 256 seconds]
<CompanionCube>
did you ever read the page about how the memory tagging works on POWER?
<geist>
IBM was always big on sayign it has 96 bits of virtual
<geist>
or 80 i mean
<geist>
when AFAICT it's simply 64bit + 16 bits of address space id
<CompanionCube>
geist: iirc the user ISA is defined as having 128-bit pointers.
<geist>
(thought actually makes me wonder how many virtual bits are implemented in POWER/PPC)?
Burgundy has joined #osdev
Burgundy has left #osdev [#osdev]
Burgundy has joined #osdev
<geist>
how woudl 128 bit pointers work without a register to hold them?
<kazinsal>
looks like Power ISA 3.1 supports between 65 and 78 bits of virtual address space
<geist>
yah but how does that work? is that simply ASID + virtual pointer?
<kazinsal>
I think so
<kazinsal>
it says "effective address space size is 2**64 bytes" on the same page
<geist>
and even that i think some amount of the 64 is not implemented, as it generaly is not
<CompanionCube>
'For 64-bit PowerPC processors, the virtual address resides in the rightmost 64 bits of a pointer while it was 48 bits in the S/38 and CISC AS/400.'
<geist>
i think the power hashtable only has 56 bits or so for the virtual address match
GeDaMo has joined #osdev
bauen1 has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
bauen1 has quit [Ping timeout: 240 seconds]
bauen1 has joined #osdev
pretty_dumm_guy has joined #osdev
mctpyt has joined #osdev
Vercas3 has joined #osdev
mctpyt has quit [Ping timeout: 268 seconds]
gog has joined #osdev
Vercas has quit [Ping timeout: 276 seconds]
Vercas3 is now known as Vercas
bauen1 has quit [Read error: Connection reset by peer]
PapaFrog has quit [Ping timeout: 240 seconds]
bauen1 has joined #osdev
Killaship34 has joined #osdev
<Killaship34>
Hi
<Killaship34>
Talking from school here, lmao
<GeDaMo>
Hi Killaship34 :)
<Killaship34>
Hi
<Killaship34>
wait who are you
<GeDaMo>
I'm GeDaMo :|
<Killaship34>
Ok, hi GeDaMo
<Killaship34>
:p
<Killaship34>
I found out how to get a terminal from my home PC at school, so here I am, running an IRC client from the terminal
<Killaship34>
I'm gonna go
<Killaship34>
bye
Killaship34 has left #osdev [#osdev]
<gog>
bye
Killaship34 has joined #osdev
<Killaship34>
Actually I'm gonna have this hanging around in the background
<gog>
hi
<Killaship34>
hi
<gog>
u writing a kernel?
<Killaship34>
Yeah
<Killaship34>
I'm Killaship on github
<Killaship34>
I have a real mode kernel, Proton
<Killaship34>
and a multiboot1 kernel, Spectrum
<Killaship34>
and some other projects with similar names
<gog>
i have a thing, it's not exactly a kernel yet
<gog>
it's called "sophia"
<gog>
it's an absolute mess
<Killaship34>
lol
<Killaship34>
Cool
<klange>
you can go a long way and still have an absolute mess
<Killaship34>
Yup
<gog>
i anticipte it's always going to be an absolute mess
<Killaship34>
Good idea]
<gog>
that's ok, i am too and i'm pretty cool
<Killaship34>
nice
<Killaship34>
;-; tfw you find a nice guy on irc but he's gone
<zid>
gog: your mess brings all the boys to the yard, but they're like, wtf is this mess, you're like, I could show you, but I'd have to cringe
<gog>
true facts
bauen1 has quit [Read error: Connection reset by peer]
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #osdev
bauen1 has joined #osdev
Killashi134 has joined #osdev
<Killashi134>
And, I'm back
<Killashi134>
hello
<gog>
wb
Killashi134 has quit [Ping timeout: 256 seconds]
<gog>
bye
Oli has joined #osdev
bauen1 has quit [Read error: Connection reset by peer]
bauen1 has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
Oli has quit [Quit: leaving]
dude12312414 has joined #osdev
Jari-- has joined #osdev
Lugar has joined #osdev
nvmd has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
srjek has joined #osdev
Sos has joined #osdev
dude12312414 has quit [Remote host closed the connection]
Jari-- has quit [Remote host closed the connection]
dude12312414 has joined #osdev
lkurusa has joined #osdev
sm2n has quit [Remote host closed the connection]
exec64 has quit [Remote host closed the connection]
gjnoonan has quit [Remote host closed the connection]
tom5760 has quit [Remote host closed the connection]
tom5760 has joined #osdev
gjnoonan has joined #osdev
sm2n has joined #osdev
exec64 has joined #osdev
ElectronApps has quit [Remote host closed the connection]
lkurusa has quit [Quit: I probably fell asleep (or went out). Who will ever know.]
mahmutov has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
<Bitweasil>
"<klange> you can go a long way and still have an absolute mess" <-- See Microsoft! ;)
<Bitweasil>
Or the Linux kernel, or...
heat has joined #osdev
nyah has joined #osdev
<heat>
is 25-26% cache misses horrible? for a terminal emulator
<heat>
yesterday i had "fun" profiling mine in linux with perf
PapaFrog has joined #osdev
<heat>
it turns out the hotspots for the terminal are just loads from memory
<heat>
which tells me the caching is all screwed up probably but I don't see how I'm supposed to make it go fast
<heat>
when I keep a render thread the speed is similar but I don't do fancy delaying of the actual thread waking up
<heat>
and I'm not sure how to go about it because I'm scared I'll introduce some sort of latency which is not what I want, obviously
[itchyjunk] has joined #osdev
<Bitweasil>
That doesn't seem terribly odd to me, most things suck at cache-behavior.
<j`ey>
heat: why not perf test another emulator?
<heat>
just tried with konsole and it has slightly lower cache misses but it's obviously much faster
<heat>
also, GPU acceleration
<heat>
my problem is that my virtual terminal is *really slow*
LostFrog has joined #osdev
<heat>
it takes 40 seconds to readelf -a /boot/vmonyx (~4300 lines)
PapaFrog has quit [Ping timeout: 240 seconds]
<heat>
actually 5300 lines but still, in konsole it's instantaneous
<Bitweasil>
I doubt your cache misses are the problem at that point.
<clever>
heat: that reminds me, i had problems on nixos when i first started, where `ls -lh` would be abnormally slow
<heat>
Bitweasil, if my instruction hotspots are an "and" with a memory operand and a "test" with a memory operand, it's not impossible
<clever>
heat: i eventually figured out why, nixos was using an out-of-tree copy of gallium i think it was, which had been deprecated after merging it into another repo
<clever>
so there was 2d accel bugs in there, that had been fixed ages ago
<heat>
i don't have acceleration at all :)
<Bitweasil>
Are you working within cache lines mostly, or romping all over memory and not even in L3?
<heat>
idk
<heat>
the only concrete measurements I did were yesterday and even those aren't really representative
<heat>
my design is dead simple: the console is represented by a big array of struct console_cell, which are 16 bytes in size and have the codepoint, fg, bg, and flags (one of which is the dirty flag)
<heat>
all commands, writing, scrolling are done directly on the console_cell array
<heat>
after the vterm_write() finishes I go around and look through the entire array for dirty cells, which is probably what's screwing me
<heat>
when flushing out cells it's just simple bitmap character drawing directly to the framebuffer
<clever>
heat: oh, and another problem, even older, when i installed a new distro on a "new" laptop, i found gnome-terminal to be a major cpu hog, but xterm was amazingly fast, ever since then, ive been stuck on xterm :P
<Bitweasil>
I've seen long running 'top' sessions in gnome-terminal start chewing up a ton of CPU as well.
<Bitweasil>
I'll have to try xterm on those systems.
<Bitweasil>
(start top, come back a month or two later, gnome-terminal is chewing... alarming amounts of the limited CPU)
<clever>
Bitweasil: that laptop also had cpufreq bugs
<clever>
`ls -lh` would chew enough cpu, that it would step to a higher freq
<clever>
but then its idle, so it steps back down
<clever>
and due to hw bugs, the system locks up solid for 0.5 seconds on every step
<clever>
and that step back down, lines up perfectly with when i react to the ls output, and type another cmd
<clever>
and the ps2 fifo overflows
<clever>
so key-up events are lost, and auto-repeat just takes off!
<heat>
holy shittttttttttttt linux devs are so smart
<heat>
how did I not see this
<heat>
their console cell array is an array of pointers
<heat>
when they shuffle lines (e.g scrolling) they can just swap pointers
<clever>
?
<clever>
ive run into scrolling performance issues on LK as well, and would be interested in options
<GeDaMo>
heat: did you see those videos from Casey Muratori where he wrote a terminal emulator on Windows?
<heat>
instead of doing a huge memmove of the whole cell array, as you would do if you just had a static one, they just move pointers
<heat>
since you have like what, 25-40 lines you need to move 25-40 lines in the worst case when scrolling the whole system
<heat>
which in our best case are just pointers
<clever>
heat: is each line of text its own image and ptr?
<heat>
GeDaMo: yes, I didn't find it too useful, lots of snark and user-space only stuff
<GeDaMo>
He basically got annoyed at MS for claiming that making their terminal faster would be extremely difficult
<heat>
I don't have a GPU here, nor do I have a chance to do fancy asynchronous processing of writes; if I take too long to do something I'm just adding latency to a program
<heat>
clever: each line of text is its own array of char32_t's
<clever>
heat: ahh
<heat>
in my case I have 4 uint32_t's
<clever>
so your manipulating the text content, and then re-rendering?
<heat>
codepoint, fg color, bg color, flags
<heat>
si
fwg has joined #osdev
<clever>
LK is very different, it has no way to store the text content
<clever>
the print routines just directly draw to the image buffer, and then promptly forget the text
<heat>
if you want to implement a vt100 emulator you need this
<j`ey>
heat: i tried to give it a watch, but yeah, so much snark
<clever>
scrolling is just a memmove() to shift the pre-drawn glyphs
<heat>
memmove() on a framebuffer is bad
<clever>
yeah
<clever>
thats why i was asking, to find another solution
<clever>
but it looks like what you found is for the text buffer, and doesnt solve re-rendering that to the gfx buffer
<heat>
helps
<heat>
if you don't read from video memory you're way better off
<clever>
ah yeah, that also came up a while back on the rpi forums
<clever>
somebody asked why reading /dev/fb0 is so much slower then writing
<clever>
and the answer is write-combined and no-cache
<clever>
but in the case of LK on the VPU, i can configure it so the video memory is cachable, and the GPU is coherent with the cache
<clever>
but i would probably use DMA on uncached memory, if i wanted to optimize it more
<heat>
i think with PCI you're also limited to a single read but you can queue a lot of writes
<bslsk05>
github.com: lk/gfx.c at master · littlekernel/lk · GitHub
<clever>
heat: when a bitmap is created, the copyrect function is filled in, with a variant suitable for the bpp, but i could swap that out with a gpu accelerated copy
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<heat_>
crap I can't get AHCI IRQs in real hardware
gdd has quit [Ping timeout: 256 seconds]
<heat_>
yeah OK I think I'm not getting IRQs at all
<heat_>
unless both my AHCI and RTC drivers are broken
kspalaiologos has joined #osdev
kspalaiologos has quit [Quit: Leaving]
<heat_>
hmmm the local apic timer works though
<clever>
heat_: check the irq controller tree?
<heat_>
no clue what you're talking about
<heat_>
this is my OS
<clever>
doesnt x86 have a thing where some irq controllers are routed into an irq pin on another irc controller?
<clever>
and if that chained pin is disabled, everything on that branch of the tree is dead
Oli has joined #osdev
<heat_>
oh wow I found the issue
<heat_>
it turns out the IO APIC's redirection table can have garbage in it
<clever>
what does the redirection table do?
<heat_>
IRQs map globally to the IO APIC's redirection table, then the IO APIC redirects the IRQ to a given local APIC with the given delivery mode
<heat_>
and asserts a given irq vector
<heat_>
I noticed it because I tried to print an entry and it had a bogus destination CPU ID
<clever>
ah
<heat_>
my init code just read the entries, adjusted a few things and kept going
<heat_>
If I set it to 0 explicitly everything is fine
<heat_>
Default value: xxx1 xxxx xxxx xxxxh <-- actually yeah they're pretty explicit about that
lkurusa has joined #osdev
heat_ has quit [Ping timeout: 240 seconds]
joe9 has joined #osdev
<joe9>
I am trying to decode this instruction into further detail ff2425910e2000 . This is in x86-64
<joe9>
It is causing a #GP(0)
<joe9>
and I am trying to figure out why. http://okturing.com/src/12985/body If I replace the JMP with a CALL or JMP to a label, it works fine.
<joe9>
So, something to do with segment selector or task gate setup, I think
<gog>
task gate?
<gog>
can't use those in long mode
<Oli>
As a brief addendum: I love you all people delving on and helping others paradigms on close-to-metal computer science topics.
<Oli>
tangent* sleepy me
<joe9>
gog, but, I do not know if it is due to that. It should not be. but, just want to be sure.
<gog>
trying to jump through a task gate in long mode will #GP(0), so it's a good starting point
<joe9>
if I want to look into the instruction components mod-reg-r/m bits, other than doing the bits manually.
<joe9>
is there a better way of going about it.
<gog>
are you trying to use x86 hardware task switching?
<joe9>
no, not knowingly.
<gog>
that's the only purpose for task gates
<joe9>
unless, I forgot to enable/disable some specific flag.
<gog>
and it's deprecated in long mode
<gog>
or rather, not supported
<gog>
it's deprecated in protected mode and not recommended
<gog>
ok hm examining this it doesn't seem like that's what you're trying to do though
<joe9>
ok, will set it explicitly to 0x10 and try. Thanks.
<gog>
has to be after you do lgdt
mahmutov has quit [Ping timeout: 256 seconds]
<joe9>
ok, thanks.
<geist>
clever: oh yeah that gfxconsole stuff is all about max compatibility, not speed
<geist>
though it does generally acknowledge the fact that you should generally write to the framebuffer and not back
<clever>
geist: and i think i could work within that framework, by adding a custom copyrect function, for any images rendered on the rpi gpu
<geist>
though if the FB is in main ram that's not really true, you can generally munge it
<clever>
yeah
<clever>
but a dma accelerated copy, would leave the cpu more idle
<clever>
and could probably saturate the bus better
<geist>
sure
elderK has joined #osdev
<clever>
but i can also see some issues, copyrect and dma, the stride, it may not play well together...
<clever>
worst case, i could see creating one control structure per row of pixels, and chaining them up
<clever>
but if the rect spans the entire image as gfxconsole does, it can be far simpler
sdfgsdfg has quit [Quit: ZzzZ]
elderK has quit []
elderK has joined #osdev
heat_ has joined #osdev
heat_ is now known as heat
vdamewood has joined #osdev
<heat>
yo geist
<heat>
do you know anything about irq balancing between CPUs?
<heat>
now that I've looked at this code I might as well improve stuff and I haven't looked too much into balancing
GeDaMo has quit [Remote host closed the connection]
<heat>
although I remember reading vague comments about having every IRQ on the same CPU being faster because of caching or something
Oli has joined #osdev
Retr0id7 has quit [Ping timeout: 250 seconds]
vdamewood has quit [Quit: Life beckons]
<clever>
heat: for nvme, you do want per-core interrupts, because nvme supports per-core command rings
<clever>
so basically, each core can talk to the nvme drive independantly, without having to do any mutex'ing to share the drive
<clever>
and it will irq back to the core that gave that specific command
srjek has joined #osdev
chartreus has joined #osdev
chartreus has quit [Client Quit]
<sham1>
That's actually neat
<sham1>
I suppose that's just one more reason why nvme is so good
<sham1>
And performant
<heat>
well a single nvme drive is a single controller afaik
<heat>
there's also not much to lock in AHCI
<heat>
each drive can operate semi independently
<clever>
i think the reason nvme does that, is 2 fold
<clever>
1: the cpu cache, if a given process just requested data, sending the reply to the same core improves the chances of that process still being in the cache
<clever>
2: less need for the kernel to co-operate with its other cores, over who talks to the drive when
blockhead has joined #osdev
<clever>
heat: xhci also gains other fun features from its use of many command rings, like exporting a usb device on an xhci controller to a virtual machine, with minimal translation involved
<clever>
you can basically just map the command ring for a given usb device right into the guest, and cover it with a very thin xhci virtual device
<clever>
though, i'm not sure what actually takes advantage of that....
Oli has quit [Quit: leaving]
orthoplex64 has quit [Remote host closed the connection]
orthoplex64 has joined #osdev
<zid>
clever: I like the idea of routing io irqs based on the cpu that is actually waiting on that io
<zid>
idk if anybody does that
<zid>
then just waking up into that processes read() straight out of the irq'd be cool
<heat>
it's pretty standard on high performance stuff
<heat>
NICs do it a lot for example
<heat>
the whole linux networking stack has a lot of optimisations for getting a packet to the CPU it belongs in directly
<heat>
now I just need to find out why my PS2 driver isn't picking up the controller and I'll have a working real thing
heat has quit [Remote host closed the connection]
biblio has joined #osdev
<kazinsal>
yeah MSI-X makes routing different queues to specific CPUs super easy
sonny has joined #osdev
<geist>
indeed. also good high performance nics have multiple queues as well, and usually let you assign a MSI-X vector per
<geist>
the assumption being that you spread them across cpus
<geist>
clever: i think that particular command ring thing in xhci is larely used for things like mass storage
<geist>
you can basically build a separate transfer queue for some disk so it doesn't have to go through the usual high level machinery of the usb stack
<geist>
the details are hazy
<geist>
or that may be that xhci controller has mass storage offload and maybe that shows up as a separate queue