Re: [gentoo-server] Re: My stab at a 2.4.22 "server" patch

[Kerin Millar]

On Fri, 2003-11-28 at 19:43, Steve Arnold wrote:
> I think you've hit the nail on the head here, as the kernel seems to
> be the one thing in Gentoo I haven't been happy with lately; I've
> tried many, including making that Planet CCRMA sources ebuild in an
> attempt to get something like the performance I get with rh9 and the
> binary CCRMA kernel.  I still haven't done it yet...

Intriguing. Has it occured to you that maybe the reason you won't get
equivalent performance is because the Redhat distro is suppoting Ulrich
Drepper's very fast, scaleable POSIX threads implementation (NPTL) in
the glibc shipped by Redhat (as well as the kernel of course)? I
revamped by desktop system to support NPTL recently and I can tell you
... it's fast. The thing is, I don't believe any Gentoo user has yet
attempted to bootstrap a glibc against 2.4 sources (probably because the
redhat/fedora kernel is the only available 2.4 sources that support it).
Also, building sys-libs/glibc with USE="nptl" expects 2.6 sources in
place. That is something I want to try soon; I think I mentioned this in
a previous post. Basically, this benefits anything that links to
pthread.so (many things). To give you but one example, I've heard of
300% performance improvements in MySQL.

Interestingly, Redhat have dropped the RMAP VM from the latest set of
sources (certainly the Fedora 1 sources). This is somewhat
dissapointing. I believe that Andrea's stock VM may appear faster under
certain useage patterns, but Rik's RMAP will hold up better under
serious stressloads (i.e. servers). That is why I hope I am capable of
patching it in, as Marc did with the WOLK kernel. 

> My one recommendation now would be to drop the lm_sensor patches (or
> don't include them) but make sure i2c is current.  Maybe you could
> even do a local use flag for stable/dev branches (I don't know what
> the i2c state is right now, so maybe that's a moot point).
>
> I'm not sure about 2.4.22, but the earlier kernel tree included a
> rather stale set of i2c modules (and no lm_sensors), whereas wolk
> includes updated versions of both.  The latter approach seems handy
> from one perspective, however, it somewhat collides with the
> lm_sensors package (since both the i2c and lm_sensors ebuilds
> over-write any existing kernel modules).
>
> I'm not sure if that's very clear, but the lm_sensor ebuild includes

Yes, I follow - the lm_sensors ebuild wants to build modules against the
current kernel sources/headers.

> both the user-space tools and modules; since a set of kernel
> patches only includes the sensor modules, it's only partially
> usable.

>
> Depending on the age/version of the kernel i2c code, I think
> adding a set of i2c patches (maybe one for each branch, since both
> branches are in gentoo already) is the best way to go.  Most of the
> kernel sources I've tried in the last few months update at least
> i2c, if not both update i2c/add lm_sensors.

Interesting. I might hit you up for some advice on how to actually use
the things! I'm not very experienced with lm_sensors. But yes, I'll keep
an eye open for any patches in accordance with your wishes.

>
> Well, that's my $.02 (other than offering encouragement).  Of
> course, I can't offer much in the way of real help until my
> crap-load of work gets at least a little smaller.

Being an experienced programmer you could perhaps help me out and show
me how to use CVS _properly_ ;)

--Kerin Francis Millar