Re: Referring what kernel-images to build to the technical committee?
On 04/26/2001 09:59:13 AM Russell Coker wrote:
>> On Thursday 26 April 2001 16:38, Ilya Martynov wrote:
>> > RC> There is no need for a MTTR specific kernel. MTTR is not really
>> > RC> needed as there is no software written which is unable to run
>> > RC> without it. Our goal here should be compatibility with software.
>> > RC> MTTR can increase speed significantly in certain situations, but
>> > RC> there's lots of other ways of doing that for less effort which we
>> > RC> aren't supporting. MTTR can allow you to work around broken
>> > RC> hardware. But we can't provide enough kernels to support all
>> > RC> combinations of broken hardware (I am sure that I could find a
>> > RC> list of a dozen boolean options which are all needed to be in one
>> > RC> state or another for various broken hardware - we can't provide
>> > RC> 2^12 kernels).
>> >
>> > I think you are wrong about 'MTTR is not really needed'. One good
>> > example is aviplay (player for avi files). It perfomance is seriously
>> > affected by MTTR option. This fact is mentioned in its docs and I've
>> > seen myself *significant* difference in its perfomance when I've
>> > compiled kernel with MTTR option. Probably perfomance of simular
>> > programs will be affected too.
>>
>> I've played many AVI files without MTRR support. It will still work,
just a
>> bit slower. If programs won't run at all (as in the case of MMX and
3DNow!)
>> then we should compile different kernels. If they just don't run as
fast
>> then we can let the users compile their own kernels.
>>
>> If you want maximum video speed you want to compile your own kernel with
AGP
>> and DRI support etc...
Naw, lets just quadruple the number of kernels we have so we can have:
1) kernel without AGP or DRI
2) kernel with AGP and no DRI
3) kernel without AGP with DRI
4) kernel with AGP and with DRI
For each of the 30 or so processor revisions that can be compiled for.
After all, if half a dozen kernels for the i386 "port" of debian is OK
instead of 1, what's wrong with quadrupling it again? The same arguements
apply to that case.
Eventually there will be so many kernels that newbies will find it quicker
and easier to navigate "make xconfig" that to navigate dselect.
And optimizations aren't just limited to playing AVIs.
I recall a few years ago a special version of mpg123 that was optimized for
a 486. A 486-33 that could barely play a mono 22.1 K mpeg easily played
stereo 44.2 K mpegs with the optimizations, if I recall correctly. We
desparately need to include that of course. I'm sure similar optimizations
could be added to mpg123 that would reduce processor load on a P4-1ghz by
0.001 % so we need to include that of course.
If we are going to recompile everything to get 1% better performance, we
should have the guts to split the i386 port into all the little processor
families instead of this halfway stuff.
Reply to: