On Sun, Apr 21, 2013 at 4:29 PM, Jiří Zárevúcky <[email protected]> wrote: > On 21 April 2013 15:52, Ján Veselý <[email protected]> wrote: >> There are two things to do: >> 1) fix fibril creation so that it won't kill the task if there is not >> enough memory. This will result in unusable mouse and probably >> stuck/ignored keys, but should prevent driver kill. >> >> 2) add single fibril interrupt handling mode to guarantee serial >> handling and hope that the added benefit of better performance is good >> enough to remedy your situation. If the performance is still not good, >> it will result in unusable mouse and stuck/ignored keys. >> >> Your setup is a nice test case so implementing 1) first might be a >> good idea. I'll try to have a look >> on both when I get some time. >> > > Without some kind of per-task resource limits, 1) will only help as > long as no task in the entire system happens to access late-reserved > pages. And there is still very little benefit in keeping a task that > consumes all memory and cpu to run for no purpose - it will be > permanently stuck anyway.
I don't see your problem with memory/cpu intensive tasks. If you want to limit impact of resource use of one task on the rest of the system, you need resource reservation and limit enforcing capabilities (this would be nice to have). The purpose of a task that consumes resources is determined by the user (directly or indirectly). If I want to run a mouse driver that consumes 1G ram and 80% of CPU there should be nothing that stops me. If I think it's excessive I can kill it. Fixing the ENOMEM task kill problem achieves just that. > 3) Maybe it would be better if the driver itself understood the > protocol and was able to combine the moves in-place instead of > buffering them needlessly. This does not make much sense. There is no needless buffering. The i8042 driver reads bytes, stores bytes, and lets the mouse driver read as many as it needs for the currently used protocol. There is no hw fifo that would store the data and fire interrupt only once the message is complete. The ps2mouse driver DOES understand the protocol and requests the exact amount of data it needs. In fact it SELECTS the protocol based on device capabilities. 1 event means one (round trip) message between the i8042 and the ps2mouse driver. Changing the i8042 driver to understand used communication protocols is a bad idea. You can have multiple devices that use different protocols connected via ps/2. It is bad enough that we force XT scna codes for AT protocol because of the kernel driver (I'd like to see that fixed one day) There is one more thing we can do about handling interrupts. The kernel could enforce interrupt rate and automatically disable irq lines that are firing too often (send one last message "irq disabled"). This will help prevent against misbehaving devices (like i8042 4000 irq/s), drivers that fail to clear interrupt in their irq handling code, and protect against spurious interrupts as well. The limit can be passed during interrupt handler registration. If the irq line is shared it would add the values. Jan _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
