This is all hypothetical. I just want to know what you all think.
Assume a dual-core or other multi-cpu environment.
In standard operating systems, when the user program wants a system service from the OS, it must make a system call that results in expensive context switching. Same thing for interrupts, they also result in context switching.
In a multiple-CPU(core) environment, what if we dedicated one cpu to running OS and even let's say another cpu for processing IRQs. That's it. All tasks on CPU 0 are kernel tasks, all tasks on CPU 1 are IRQ handling taska, and user programs are relegated to CPU 2+.
Wouldn't this completely eliminate any latency of system calls and IRQs? Has this already been done? Would performance gains be better this way or just having all tasks distributed equally among all available CPUs?
Name:
Anonymous2006-09-02 4:33
WHAT THE SHIT IS THIS IRQ 1970S TECHNIQUE?? HUH???!
Name:
Anonymous2006-09-02 5:07
Wouldn't this completely eliminate any latency of system calls and IRQs?
No.
If you have more processes than CPUs, you'll still have a context switch on at least some of the CPUs.
If you have less processes than CPUs, you'll be running everything concurrently, except when a process needs IO, in which case you have a one producer/many consumer problem with the OS running on one CPU.
And of course, this entirely ignores that CPUs have hardware interrupts. Without an OS on every CPU, who is going to deal with these? The programs? Not a good idea.
Name:
Anonymous2006-09-03 12:33
>>1
Conversation with you on this topic would be pointless, seeing as you do not understand the construction of operating systems. Next you'll be saying that eliminating interrupts will eliminate interrupt latency. Yeah, ok.
People, this is what happens when newbies are fed big words they kinda-sorta get but don't actually understand the meaning of. They start talking about how "IRQ latency" is eating the "horsepowers" of their "rig".
Name:
Anonymous2006-09-03 13:38
>>4
Getting rid of interrupts? HA! What a great idea.
No, I know interrupts cannot be removed completely (esp. since >>3 is right, CPU itself generates interrupts) but how about a design whereby the interrupt controller is replaced by a CPU that can also host the interrupt handler code?
>>5
Yet, to be useful, the interrupt handler needs to cause other code to be executed besides itself. If one of the processors is dedicated to only serving interrupts, then the interrupts cannot have an effect anywhere. (Unless they'd change a memory location and the other processors would poll that memory location... in which case, enjoy your software PIO!)
Guess what? Apart from polling, processor-to-processor communication happens using the almighty cross-processor interrupt. Which once again implies an interrupt handler. Ain't living great?
In a nutshell, shitty idea, shitty thread.
Name:
Anonymous2006-09-04 19:16
>>9
From what I understand, interrupts are handled in this fashion:
1. Device asserts IRQ
2. CPU saves current state and enters IRQ handler
3. Interrupt handler executes, which usually just brings device to non-interrupt state and saves whatever data to be processed by a DPC
4. CPU restores state/exits IRQ handler
5. DPC is executed which processes data gathered in step 3 and then makes data ready/issues signal (another interrupt) or whatever if needed
So, let's say for one device that requires one IRQ, why not have a process running on a dedicated CPU that does nothing else but PIO-style poll that particular device and then do step 5 when it has data ready. This would eliminate steps 2 and 4, increasing performance.
Name:
sage2006-09-05 20:25
not practical on von neumann paradigm architecture
re: 3, "Usually" is a bad thing to limit an architecture to. Usually is not always, and the exceptions toss you into >>9's description.
Name:
Anonymous2006-09-09 11:47
>>10
Bzzzzzt. Interrupts can interrupt lower-priority interrupt handlers too. That's where most of the so-called "interrupt latency" comes from.
AND YOU NEGLECT THE FOREMOST MATTER, which is that _something_ needs to goddamn _happen_ due to an interrupt! You can't just "stick one CPU to work on interrupts" and shove your head into the sand and expect that the programs on the other processor would notice or be in any way informed of interrupts occurring on the other processor!
Plus, timekeeping is done with a timer interrupt. It's pretty important for, you know, preemptive multitasking.
Name:
Anonymous2006-09-09 13:46
Yes. I'm a C programmer. So? I don't see a problem. I embraced my UNIX soul long ago and I am happy together with my compiler (who is a cute layered front/backend design!). We have a fucking lot of functions in and outside of the kernel and I am pretty compact and resource conserving.
But thanks anyway asshole. Go and beat off to your stupid garbage collection shit while I #INCLUDE <stdio.h> with my preprocessor.
Bringing /prog/ back to its people
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy