On 21 April 2013 17:56, Ján Veselý <[email protected]> wrote: > 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. >
I am confused how intentionally using the worst way to deal with a problem is good for anything. Sure, some handling is "best effort" at most, but if we use an obviously inferior way to do something, I think we do it just wrong. There is no technical reason to let a driver buffer gigabytes of data it can't reasonably use. My problem with memory/cpu intensive task is when it can be easily fixed. You do not deliberately program a resource bomb into drivers. You... just... do... not. It is just a lousy implementation of something that can be done much better. And it's not even difficult, dropping interrupts requires a few lines of code and it just makes an already unusable pathological behavior less pathological. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
