On Wed, 5 Nov 1997, Andre Derrick Balsa wrote:
> Hello,
>
> Teunis, I would *not* want to see the (fixed) 2.1.39 Cyrix patch go into
> the kernel source, as it stands now.
>
> I have a simple technical reason, and a more "philosophical" reason for
> this.
>
> Technical: no performance gains
> ==========
>
> The main performance improvement that can be had by adapting Linux
> operation to a 6x86 processor is the correct setup of the ARR registers.
> This can bring a 30-50% CPU/video memory bandwidth improvement.
>
> The 2.1.39 patch does *not* set the ARRs, because this would imply the
> detection of the linear frame buffer address, which changes from system
> to system.
>
> The other performance features bring a *measured* performance
> improvement of less than 0.5%. This is insignificant IMHO.
>
> Philosophical: kernel pollution vs. user-space utility
> ==============
>
> Everything (nearly) the patch does can be done in user-space using the
> set6x86 GPLed utility written by Koen Gadeyne. You don't have to
> recompile your kernel everytime a 6x86 feature needs to be tested or
> changed. And set6x86 allows setting the ARRs.
>
> The only thing set6x86 cannot do is implement the 6x86 VSPM feature,
> which only works in some 6x86 revisions, has been dropped in the new
> 6x86MX and does not provide any measurable performance improvement.
>
> So I would prefer to keep the kernel source as clean as possible,
> without adding every possible trick or gadget (this also applies to
> other tricks and gadgets that unfortunately have gone into the kernel
> source, sometimes causing strange side-effects).
>
> In some cases a patch is needed, but the 2.1.39 Cyrix patch is not.
>
> OTOH it's an excellent patch and I thank Mike Jagdis (the original
> author) for it. It's a clean patch and the accompanying documentation is
> of the highest quality (quite exceptional when it comes to kernel
> patches).
>
> I will give you another example of something that should be set using a
> user-space utility: IDE driver parameters. We have hdparm thankfully,
> but imagine what would have happened if M. Lord had decided to make all
> the hdparm options kernel compilation option? I guess he made a good
> decision, and I propose we follow his example when it comes to the cyrix
> 2.1.39 patch.
>
> Cheers,
>
> ========================================================
> Andrew D. Balsa
> Please remove the .nospam suffix in the Reply-to address
> My true email address is andrewbalsa@usa.net
> ========================================================
>