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

[Andrea Arcangeli <andrea@suse.de>]

On Fri, Feb 27, 2004 at 10:45:21PM -0800, Martin J. Bligh wrote:
> 
> > 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)

thanks for maintaining this bit too, very helpful!

> > 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.

I read the 3.5:0.5 PAE sometime last year and it was pretty
strightforward too, the only single reason I didn't merge it is that
it had the problem that it changed common code that every archs depends
on, so it broke all other archs, but it's not really a matter of
difficult code, as worse it just needs a few liner change in every arch
to make them compile again. So I'm quite optimistic 2.5:1.5 will be
doable with a reasonably clean patch and with ~zero performance downside
compared to 3:1 and 2:2.

In the meantime testing 2:2 against 4:4 (with a very/too reduced ipcshm
in the 2:2 test) still sounds very interesting.

> > 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.

full objrmap can certainly release 8 bytes per page, 128M total, so
quite an huge amount of ram (that is also why I'd like to do the full
objrmap and not only to stop at the file mappings ;).