[PlanetCCRMA] two kernel patches sets merged

[Florin Andrei]

Ok, i merged the PlanetCCRMA kernel patches set and the Con Kolivas
kernel patches set.

Reasons:
While the PlanetCCRMA kernel does an excellent job at keeping the audio
data flowing to the hard-drive, its interactive performance is poor.
Even non-interactive tasks, such as CPU-intensive encoders, run
noticeably slower.
Some applications pause for _long_ times (seconds) with no apparent
reason on otherwise idle systems. I think that behaviour is not normal.

So i took the main patches from the PlanetCCRMA set and combined them
with the Con Kolivas patches set. No rejects, the patches applied to the
kernel and then the kernel compiled just fine.
The actual kernel tarball (2.4.21) is not included, just the patches and
a script to apply them to the kernel.

http://florin.myip.org/projects/media-kernel/

I'm running it as i write this message. So far, i couldn't see how this
kernel is worse than the PlanetCCRMA one. I was able to record sound
with Ecasound and Rezound without any problems. Truth is, i didn't run
yet any extensive tests to stress the system and see which kernel gives
up first.

OTOH, this kernel is _extremely_ responsive. My system felt like a
PIII/600 under the plain PlanetCCRMA kernel for normal desktop usage,
now it's back to its AthlonXP/1800 own self. :-)
The long-term CPU usage average is lower with the combined kernel, which
makes me think this kernel might be more robust than the PlanetCCRMA one
when it comes to CPU stress (i don't have a proof for that though).

Also, it includes the XFS patch. This is required because i want to be
able to capture high-bitrate video streams, and XFS has the best
performance for fast massive writes (writing many MB/s into large files)
and fast massive reads (reading as fast as possible from multi-GB
files); true, it's slower than ReiserFS for things like deleting large
trees with many small files, but i don't care about that; true, it's
somewhat more fragile than Ext3 if you hit the power button but i don't
care about that.
So this way the disk I/O should get a boost.

You have to compile the kernel yourself. No RPMs, sorry.

It would be interesting to perform head-to-head comparison tests with
the PlanetCCRMA kernel and the combined kernel, to see which one works
best in different situations, while recording an audio stream to the
disk using ALSA/JACK/some-DAW-app. Various system stresses might be
used: pure CPU stress, pure disk I/O stress, combined stress, etc.
If anyone plans to do that, please give a shout so that we wouldn't
duplicate efforts (i may do some tests myself, but not too soon).

Also, if someone figures out a way to make bootsplash work, give me a
message please. :-) Mine doesn't, it looks like a mismatch between the
kernel patch and the userland tools.

Comments are welcome.

-- 
Florin Andrei

http://florin.myip.org/