|
From: Daniel G. <da...@fp...> - 2005-01-13 03:44:35
|
On Wed, 2005-01-12 at 19:26 +0000, Kristian Van Der Vliet wrote: > This scheme turned out to be tricky to implement, with no real benefit over > the current scheme. It suffered from a "ping pong" problem where the dynamic > priority would ping-pong between two values as the algorithm fought over > itself. Certain threads were also very suseptable to what appeared to be > priority inversion E.g. the desktop thread at login would use a large amount > of CPU time, get down to a certain low priority and then hang, likely > deadlocked with another thread. The testcase showed less of an improvement > also, so the net benefit was smaller. > > I didn't get more testing done as I really need to rebuild my machine; it has > remnants of Glibc 2.3.3 testing on it which are playing havoc. Once I've got > it back to a clean state I'll get back to fiddling with some different ideas. > So, I fared a bit better than you did. I could log in, and use by box normally, as far as I could tell. However, if I tried to run a sync command, the box locked up, with nothing being printed in the kernel log. This was repeatable: sync -> lockup. Of course, neither the original kernel nor your hacked up one caused such a lockup. Back to the drawing board, I guess. (If anyone's interested, I can post my patches...) On a side note, has anyone gotten sshd working? It would make development, if not testing, easier. Daniel |