Re: 2.4.23aa2 (bugfixes and important VM improvements for the high end)

[Martin J. Bligh]

> thanks for giving it a spin (btw I assume it's 2.4, that's fine for
> a quick test, and I seem not to find the 2:2 and 1:3 options in the 2.6
> kernel anymore ;).

ftp://ftp.kernel.org/pub/linux/kernel/people/mbligh/patches/2.6.3/2.6.3-mjb1/212-config_page_offset
(which sits on top of the 4/4 patches, so might need some massaging to apply)

> What I probably didn't specify yet is that 2.5:1.5 is feasible too, I've
> a fairly small and strightforward patch here from ibm that implements
> 3.5:0.5 for PAE mode (for a completely different matter, but I mean,
> it's not really a problem to do 2.5:1.5 either if needed, it's the same
> as the current PAE mode 3.5:0.5).

I'm not sure it's that straightforward really - doing the non-pgd aligned
split is messy. 2.5 might actually be much cleaner than 3.5 though, as we
never updated the mappings of the PMD that's shared between user and kernel.
Hmmm ... that's quite tempting.

> starting with the assumtion that 32G machines works with 3:1 (like they
> do in 2.4), and assuming the size of a page is 48 bytes (like in 2.4, in
> 2.6 it's a bit bigger but we can most certainly shrink it, for example
> removing rmap for anon pages will immediatly release 128M of kernel
> memory), moving from 32G to 64G means losing 384M of those additional
> 512M in pages, you can use the remaining additional 512M-384M=128M for
> vmas, task structs, files etc...  So 2.5:1.5 should be enough as far as
> the kernel is concerned to run on 64G machines (provided the page_t is
> not bigger than 2.4 which sounds feasible too).

Shrinking struct page sounds nice. Did Hugh's patch actually end up doing
that? I don't recall that, but I don't see why it wouldn't.

M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/