Date: Wed, 03 Mar 2004 07:54:39 -0800
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Andrea Arcangeli <andrea@suse.de>, linux-kernel@vger.kernel.org
cc: Hugh Dickins <hugh@veritas.com>,
       William Lee Irwin III <wli@holomorphy.com>,
       Dave McCracken <dmccr@us.ibm.com>
Subject: Re: 230-objrmap fixes for 2.6.3-mjb2
Message-ID: <8030000.1078329278@[10.10.2.4]>
In-Reply-To: <20040303070933.GB4922@dualathlon.random>
References: <20040303070933.GB4922@dualathlon.random>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2392
Lines: 48


--Andrea Arcangeli <andrea@suse.de> wrote (on Wednesday, March 03, 2004 08:09:33 +0100):

> While merging 230-objrmap in my tree I spotted 2 bugs potentially
> generating random memory corruption and 1 superflous bit that I dropped
> (mostly for documentation reasons, I like strict and in turn self
> documenting). Here below the fixes.

Looks good to me, but Dave is more familiar with this stuff ... Dave?

> I'm running some shm swap regression test on this right now and I'll
> leave it running for a day. In a few hours I will proceed starting
> dropping the pte_chain from the page sturcture and then I'll test the
> anon swapout. I will also follow the 6 great-effort anobjrmap posted by
> Hugh against objrmap while doing that, they're quite old (almost 1 year)
> but they still apply cleanly by hand so they're useful.

Bill has been keeping that up to date  - he may have some more recent
changes somewhere?

> About 2.5:1.5 it seems not everybody is happy to lose 512m (and it's not
> Oracle), but before ruling it out I'd like to get some real life number,
> to be sure the performance of 2.0^W4:4 are really close (if not
> "better") than 3:1 as someone said. If we go with 4:4 IMHO at the very
> least the vgettimeofday backport from x86-64 is a must. In the meantime

John has that going - there's a copy in 2.6.3-mjb1, but it has a problem
at the moment on some boxes, which he's trying to fix up. I've been 
pushing for the same thing - fixing the most common syscall will help ;-)
We're trying to get some numbers here, but have had a small setback with
some disk problems - should be this week still though.

> I keep going with the rmap removal to fixup the fork  and to get back
> the 128m of normal zone useful on the 32G boxes. Could be also that new
> cpus are a lot better at reloading the tlbs from the pagetables dunno,
> the first numbers I recall about 4:4 predates to 2000 when PII was quite
> optimal.  I'd only like to see an opteron and a xeon dealing with 4:4.

Makes sense. But why would you want 4:4 on opteron? I'm not sure we care
about the perf for anyone nutty enough to run a 32 bit kernel there ;-)

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