Date: Wed, 28 Nov 2007 23:20:33 +0100 From: Kris Kennaway <kris@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: Brooks Davis <brooks@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: RFC: libkse*.a in 7.0 Message-ID: <474DE9B1.2050408@FreeBSD.org> In-Reply-To: <474DE26F.4000303@elischer.org> References: <20071128211022.GA74762@lor.one-eyed-alien.net> <474DE26F.4000303@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?474DE9B1.2050408>