O1int patch with contest

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've had some (off list) requests to see if the interactivity patch I posted shows any differences in contest. To be honest I wasn't sure it would, and this is not quite what I expected. Below is a 2.5.73-mm1 patched with patch-O1int-0306271816 (2.5.73-O1i) compared to 2.5.73-mm1 with contest
(http://contest.kolivas.org).

no_load:

Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.73-O1i          1   78      93.6    0.0     0.0     1.00
2.5.73-mm1          1   77      94.8    0.0     0.0     1.00
cacherun:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.73-O1i          1   75      97.3    0.0     0.0     0.96
2.5.73-mm1          1   75      98.7    0.0     0.0     0.97
process_load:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.73-O1i          1   94      78.7    39.0    20.2    1.21
2.5.73-mm1          2   108     67.6    67.0    29.6    1.40
ctar_load:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.73-O1i          1   86      84.9    0.0     0.0     1.10
2.5.73-mm1          3   103     74.8    0.0     0.0     1.34
xtar_load:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.73-O1i          1   92      80.4    1.0     3.3     1.18
2.5.73-mm1          3   113     66.4    2.0     4.4     1.47
io_load:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.73-O1i          1   101     73.3    24.6    12.9    1.29
2.5.73-mm1          4   127     59.1    39.7    16.5    1.65
io_other:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.73-O1i          1   95      78.9    22.7    11.6    1.22
2.5.73-mm1          2   112     67.9    43.0    19.6    1.45
read_load:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.73-O1i          1   92      80.4    2.7     2.2     1.18
2.5.73-mm1          2   100     76.0    7.8     7.0     1.30
list_load:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.73-O1i          1   87      86.2    0.0     1.1     1.12
2.5.73-mm1          2   93      80.6    0.0     7.5     1.21
mem_load:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.73-O1i          1   84      86.9    35.0    1.2     1.08
2.5.73-mm1          2   114     68.4    54.0    1.8     1.48
dbench_load:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.73-O1i          1   222     33.3    2.0     31.5    2.85
2.5.73-mm1          4   365     20.8    5.0     48.2    4.74

I promise I didn't tune it with contest results in mind. There are still things I want to do to it that may not affect these results.

Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+/FekF6dfvkL3i1gRAhHUAJwOiLq+u3nEGn9Ym+c5x4JpTqrK1ACfX79F WKLTsbtqwXyFpOZ+i+JvgVU=
=nQk2
-----END PGP SIGNATURE-----

These are good news, indeed. The patch is getting better and better, but I'm still seeing XMMS audio skips when clicking on a URL inside Evolution (and using Konqueror as my web browser), and sometimes when moving windows around.

Also, it seems that nicing the X server to -20 causes it to get CPU at discontinuous bursts, causing window movement to be somewhat jerky. The overall feeling for the X server is better at a default nice of 0. Isn't this curious?

Not curious at all. I should have made it clear I was in _no_ way recommending renicing X. It should be left at nice 0 and the scheduler decide what is interactive. Renicing X will guarantee you of getting audio skips.

There is still the problem of apps started during heavy loads. While the last patch helps a little, I have to do some more work on the algorithm and make it smarter to help a lot.

Con

Hi!

Could you tell exactly how you make xmms skip? I can't make it skip here, even with a make -j20. Not that I'm complaining, but I just want to track this behaviour. The only time it skips is when my cd plays a track scratched 8)

Roberto

Hi Con,
It looks like the patch is starving the background loads. read_load for example can use up to 7% (maybe more) of the CPU. It is brought down to 2.2%, list_load is worse.