> correct. but it is limited only to:
> 1. accessing ***vmalloc**** space ***directly*** . You can access any
> kmalloc'ed address directly , and access vmalloc'ed space by walking
> on the pages. what I mean is that you can access everything.
> 2. unable to kmalloc
> 3. unable to free memory. ( For example : kfree ).
What's dangerous about accessing vmalloced space directly if it's pinned? Or did I misunderstand?
> You can access any facility in the kernel. you can send or receive
> packets. and I do it on AMD-Intel machines successfully.
Though those facilities may not access vmalloc space directly, nor allocate/free memory? Seems very fragile, because you can't know if they will in the future (assuming you audited all the code that may be executed by those facilities, which is a lot of tricky work).
How can you send and receive packets if you can't allocate the space needed for them? Not with the standard networking stack, can you?
> gettimeofday is not a timer, it is a clock. try and schedule a task to
> be run T microseconds from now, you will skew, and the more tasks, it
> will skew more.
Right, totally different, sorry. But you only run one task, so the timer is just a more efficient way of not doing anything in the meantime?
> even with NAPI you may get your system to be jammed, and worst of all
> even with unrelated traffic, offsched suggests another approach of
> containing incoming traffic to a single or more cores. This way cpu0,
> the main operating system processor, will not be at risk.
This is a generic problem: Any (user or kernel) process can use too many resources, slowing down the machine as a whole. Offsched doesn't solve that at all, except for some explicit kernel cases which are 'ported' to offsched, which is a lot of work.
realtime preemption, on the other hand, tries to solve this problem in a more generic way.
And moving networking to offsched may contain the damage to one core, but it doesn't solve the real problem, e.g. sshing into the box doesn't work quicker or better in any way. If the NIC generates more packets than can be handled, the right solution is to drop some early. Basically what you always do in an overload situation: Don't try to do everything, drop some stuff.
Now the nasty thing is that it's hard to see the difference between a DoS and just a very high load.
Besides, handling the network packets with all cores instead of one may be the difference between being DoSed and just slowed down.
> you cannot run user space with interrupts disabled. So you probably
> meant kernel space, and it will look something like this:
Bad wording on my part, sorry. No, I meant that all interrupt handlers are executed on other cores than the "special" one, and the few that would happen anyway are disabled semi-permanently. (The scheduling clock can be disabled because a rt task is running and no involuntary scheduling should happen. Easier now with dynticks though.)
Basically moving the special kernel task running on that core to a special user space task running on that core. Or at least add it as an option. Add some special syscalls or character drivers to do the more esoteric stuff and voila, all done.
> but you will fail.
> a processor must walk trough a quiescent state ; if you try it, you will
> have RCU starvation, and I have been there... :) . one of my papers
> explains that.
This problem is still there though. But it seems like a minor adjustment to RCU to teach it that some cores should be ignored, or to keep track if some cores did any RCU stuff at all (perhaps it already does that now, didn't check).
All in all what you more or less have is standard Linux kernel besides a special mini-RT-OS, running on a separate core. Only, you extend the current kernel to include the functionality of that RT-OS, and use other bits and pieces of the kernel when convenient. This is better than a totally separate RT-OS, but still comes with the disadvantages of one: Very limited and communication with the rest of the system is tricky. If done well it's a small step forwards, but why not think bigger and try to solve the tougher problems?