O16.2int

Hi Con

First of all, thanks a lot for all the hard work on the scheduler. A lot of people are looking forward to 2.6 and your work is a major part of the desktop user elements of this next kernel generation.

I am not one of those who can judge much difference from 15 to 16 e.g. but I do know that not using any of your patches is a major step back in interactivity and general feeling of responsiveness of my system. Been using your patches since the 6th iteration. Back then juk (the kde jukebox thingy) was a major skipping candidate under heavy load, which nowadays is almost smooth as silk.

I am pretty sure when 2.6.0 is released on the world your scheduler is that fine tuned and matured to make the new kernel a must have for everyone. And you will get there even when you do not work late at night each day to get the latest improvments to us as fast as possible hehe. Just to keep you from too many sleepless nights ;)

Until then I will continue applying your patches as soon as they get out and look out for anything suspicious that might catch my attention =)

Keep up the great work!

--
Ben

Hi Con,

I've been unable to test many of your patches lately, but I recently upgraded to 2.6.0-test3-mm2 and included the O16.2 patches and I'm having some very bad behaviour. I'll try to describe it the best way I can.

The worst case scenario involves wine applications (a program that seems to be causing a significant amount of trouble) but I think I've seen the issue in several other applications as well.

1. -- Wine running Windows Media Player 6.4 works great when running in a window but if you make the program open to full screen it gets so much attention that it almost completely starves the entire system, you can't even manage to get switched back to the standard screen. If you get very lucky you can switch the system to a VT and manage, painfully slowly to kill the wine process off, then the system will turn to normal. This issue actually seems to affect almost any wine applications that's doing a lot of screen updates, for example small flash animations work OK, but complex animations can cause many seconds of starvation to the rest of the system. Renicing the X server and wine server to much lower numbers seems to make this issue go away.

2. -- Adobe Acrobat 5.07 for Linux seems to have a very similar issue, a large complex document seems to starve out the whole system making the system feel locked up for several seconds.

3. -- It seems I can trigger the same kind of starvation by simply doing large selects in a Konsole window. Selecting a large section of text which causes the window to scroll can sometime make the system almost totally non-responsive in every other window.

The wine issue is the easiest to trigger, the others seem to require that some other things are also using CPU. In other words, if the system is otherwise totally idle I have been unable to trigger the Konsole issue, however, if another application is using a reasonable amount of CPU, say a video playing in Wine using ~50% CPU, then it seems easy to make this happen. Once it happens it's very hard to recover, the systems almost completely fails to respond to mouse button clicks and keyboard functions (although the mouse usually continues to move smoothly) if I get lucky I can get to a VT and eventually login and kill something off, but this sometimes takes minutes (it took 90 seconds earlier today just to get the password prompt after type in my username at the VT prompt and another minute to get to a shell).

Later,
Tom

Quoting Tom Sightler <[email protected]>:

Hi Tom

Yes a well known problem now (see other threads about wine). Wine doing something very cpu intensive exhibits this due to a combination of wine breakage brought out by my scheduler tweaks causing priority inversion.

Actually I've profiled acroread and it seems to be more a memory issue than a scheduler one per se. Something very inefficient about it's design and it behaves much worse as a mozilla plugin than standalone. Give it lots of cpu time and it just keeps doing more and more vm work.

This is because of wine, not the Konsole which behaves fine, but tips the combination of wine and something else over the edge.

I'm working on it. Thanks very much for your report.

Cheers,
Con

Acrobat has a switch so that it keeps a cache of rendered pages, and obviously it default to ON, so just reading a big PDF file page by page will trash all the system with lots useless data. BUT, for simple PDF usage in a non-multitasking single-user machine it's faster so there you have a possible reason for it's strange behaviour.

winden/network

1. Dado un programa, siempre tiene al menos un fallo.
2. Dadas varias lineas de codigo, siempre se pueden acortar a menos lineas.
3. Por induccion, todos los programas se pueden
   reducir a una linea que no funciona.

Yes. As well as this though, there is a specific problem with it as a mozilla plugin. Profiling shows some libgdk is doing all the work and it really behaves badly. Put the same plugin into a different browser (eg opera) and it behaves well, working pretty much like standalone acroread.

Con