Recent changes to patches

CVS 2.4.20 separation hacks

John Richard Moser — Mon, 13 Oct 2003 21:22:15 -0000

I've hacked at the CVS code for 2.4.20-cc and it runs
fine on my laptop this way. It does NOT like the
nvidia driver and doesn't seem to like `iptables -t nat
-I POSTROUTING -o eth0 -j MASQUERADE` at all. Please
locate someone with some sort of GeForce or TNT card
who can make this work, and also try to figure out why
iptables doesn't work. I'm using Gentoo Linux and this
patch on a 2.4.20 stable vanilla kernel.

as always, `cd /usr/src/linux-2.4.20 && bzcat
patch-linuxcompressed-2.4.20 | patch -p1`

No real major changes other than some code
reorganization. A few new bugs/bad hacks. I'm still
not done but in case I destroy it, here's my progress
so far. I need to figure out where the heck the code
is for writing the meta-data to swap, and I'm
COMPLETELY rewriting that because it looks messy to me.
The code in get_comp_data() looks like it's dependant
on the exact structure of the metadata. I'll simply
use a structure comp_cache_metadata{} and skip by
sizeof(struct comp_cache_metadata), then
memcpy(start_of_meta_data, sizeof(struct
comp_cache_metadata), metadata_struct) (after looking
up how memcpy really works). This way the metadata can
be changed easily, whenever, without running all around
and trying to rewrite all the low-level handling code.

Linux 2.4.20 vanilla patch (DAMAGED)

John Richard Moser — Wed, 27 Aug 2003 00:29:45 -0000

This is a 2.4.20 patch. X won't start and I get
"Illegal Instruction" from the XKeepsCrashing binary
gentoo tries to run. It's damaged, yes, but it's a
start. *try* to fix it . . . I can't.

Linux 2.4.21 vanilla kernel patch

John Richard Moser — Sun, 10 Aug 2003 16:16:05 -0000

It works. I had to apply some of the patch by hand
from the .rej files. I've tested it, it seems to work
fine for 2.4.21 kernels.

Word of caution: I've altered the damn thing a bit.
You don't have a double-size bool anymore; instead, you
have a choice of:

PAGE SIZE:
Single
Double
Quad
8x
16x
32x
64x

Major caution here: 64x performs inferior to 32x,
because it has a lot of failed alloc's. ALSO, when it
hits up of 200 failed alloc's the system simply halts
violently--I THINK. It might do other nasty things on
other machines. I've seen 37% average on 64x (same as
double-size IIRC), and 43% average on 32x. I hit >200
failed alloc's in about 10 minutes running X with
gnome2 on 256 MB RAM.

32x is prone to far less failed alloc's (been running
all night, have 51 now), and thus gets better ratios
because it's managing to actually compress things now.
However it's getting some and that does NOT look stable.

I recommend 8x or less, although I'm going to try for
16x here in a minute. I don't feel like scanning
through the source and trying to find each usage of
COMP_PAGE_SIZE and hacking it to use a kernel command
line option, but I think I have a way to do that easier
and will look into it. I'll use COMP_PAGE_SIZE_DEFAULT
instead, and define COMP_PAGE_SIZE to point to a global
external variable. This variable can be set at boot
before the driver is activated. You can clean up the
cruft behind me.

--Bluefox Icy