Re: page fault scalability patch final : i386 tested, x86_64 support added

Andi Kleen
2004-08-28T01:02:53Z

On Fri, Aug 27, 2004 at 05:36:41PM -0700, Andrew Morton wrote:
> "David S. Miller" <davem@davemloft.net> wrote:
> >
> > On Fri, 27 Aug 2004 17:19:11 -0700 (PDT)
> > Christoph Lameter <clameter@sgi.com> wrote:
> >
> > > That is still 2^(32+12) = 2^44 = 16TB.
> >
> > It's actually:
> >
> > 2 ^ (31 + PAGE_SHIFT)
> >
> > '31' because atomic_t is 'signed' and PAGE_SHIFT should
> > be obvious.
> >
> > Christoph definitely has a point, this is even more virtual space
> > than most of the 64-bit platforms even support. (Sparc64 is
> > 2^43 and I believe ia64 is similar)
>
> When can we reasonably expect someone to blow this out of the water?
> Within the next couple of years, I suspect?

With 4 level page tables x86-64 will support 47 bits virtual theoretical.
They cannot be used right now because the current x86-64 CPUs have
40 bits physical max and it is currently even hardcoded to 40bits,
but I planned to drop that in the 4 level patch (in fact I already did)
so that the kernel will in theory support CPUs will more physical memory.

> It does look like we need a new type which is atomic64 on 64-bit and
> atomic32 on 32-bit. That could be used to fix the
> mmaping-the-same-page-4G-times-kills-the-kernel bug too.

Yep. Good plan. atomic_long_t ?

>
> > and this limit actually
> > mostly comes from the 3-level page table limits.
>
> This reminds me - where's that 4-level pagetable patch got to?

It exists on my HD, but is not really finished yet.

I was on vacation and travelling and had some other things to do, so it got
delayed a bit, but I hope to work on it soon again.

-Andi