RFC: libkse*.a in 7.0

[Kris Kennaway]

Julian Elischer wrote:
> Brooks Davis wrote:
>> A number of people have proposed a direction in 8.0 that would remove
>> support for the syscalls and kernel data structures required by libkse.
>> Apparently this would enable significant simplification of portions of
>> the kernel, but I have no deeply held personal opinion.  The intent is
>> that if that happens, alternate versions of the necessicary dynamic
>> libraries will be supplied in updated compat#x packages.  This will
>> address most consumers.  The one set of consumers that would not be
>> addressed is those who have statically linked, threaded binaries using
>> libkse.
> 
> Actually the simplifications in the kernel are almost negigable.
> KSE support is almost totally contained within kern_kse.c at this time.
> When KSEG support was removed, most of the changes outside of htis file 
> were removed..
> 
> the remaining changes not in that file could be moved to that file 
> relatively easily.
> 
>>
>> Kris and I realized that if we went that route, life would be
>> significantly easier if it was difficult to create statically linked,
>> binaries using libkse under FreeBSD 7.x.  As a result I would like
>> to commit and MFC the following patch which disables building and
>> installing libkse*.a in the default case.  This would mean that
>> significant effort would be required to create a statically linked
>> application that uses the KSE syscalls.
>>
>> I believe that removing libkse*.a has little downside and leaves the way
>> open for either removing or enhancing the KSE system and is the right
>> thing to do.
> 
> If you wish.. however the performance downside of KSE is that we have 
> not run schedgraph on it and looked at what happens, rather than it being
> against a wall of some sort.. the fact that it is slower than thr in 
> most cases is because there is a bug that stops it from scheduling 
> correctly.
> 
> As I have not had the time or extreme burst of energy needed to find 
> this bug
> it has not been found, but the fact that it rarely schedules threads 
> onto > 1 cpu at a time is not inherrent in the design.

Well I think that after N years with no-one working on fixing KSE 
performance it is not reasonable to expect that this will change in the 
near future.  Absent that, and given that KSE is about 2 orders of 
magnitude slower than libthr on application benchmarks, and has shown no 
performance improvement at all since 5.x, I don't think there is any 
compelling argument to leave it in the tree in 8.0-RELEASE.

Anyone who thinks otherwise still has some time to work on fixing the 
performance issues though, of course.

Kris