Date: Thu, 04 Mar 2004 09:35:13 -0800
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Andrew Morton <akpm@osdl.org>, Peter Zaitsev <peter@mysql.com>
cc: andrea@suse.de, riel@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: 2.4.23aa2 (bugfixes and important VM improvements for the high end)
Message-ID: <132310000.1078421713@flay>
In-Reply-To: <20040303200704.17d81bda.akpm@osdl.org>
References: <20040228072926.GR8834@dualathlon.random><Pine.LNX.4.44.0402280950500.1747-100000@chimarrao.boston.redhat.com><20040229014357.GW8834@dualathlon.random><1078370073.3403.759.camel@abyss.local><20040303193343.52226603.akpm@osdl.org><1078371876.3403.810.camel@abyss.local> <20040303200704.17d81bda.akpm@osdl.org>
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: 1906
Lines: 45

> Peter Zaitsev <peter@mysql.com> wrote:
>> 
>> Sorry if I was unclear.  These are suffexes from RH AS 3.0 kernel
>>  namings.  "SMP" corresponds to normal SMP kernel they have,  "hugemem"
>>  is kernel with 4G/4G split.
>> 
>>  > 
>>  > > For CPU bound load (10 Warehouses) I got 7000TPM instead of 4500TPM,
>>  > > which is over 35% slowdown.
>>  > 
>>  > Well no, it is a 56% speedup.   Please clarify.  Lots.
>> 
>>  Huh. The numbers shall be other way around of course :)   "smp" kernel
>>  had better performance of some 7000TPM, compared to  4500TPM with
>>  HugeMem kernel. 
> 
> That's a larger difference than I expected.  But then, everyone has been
> mysteriously quiet with the 4g/4g benchmarking.
> 
> A kernel profile would be interesting.  As would an optimisation effort,
> which, as far as I know, has never been undertaken.

In particular:

1. a diffprofile between the two would be interesting (assuming it's
at least partly increase in kernel time), or any other way to see exactly
why it's slower (well, TLB flushes, obviously, but what's causing them).

2. If it's gettimeofday hammering it (which it probably is, from previous
comments by others, and my own experience), then vsyscall gettimeofday
(John's patch) may well fix it up.

3. Are you using the extra user address space? Otherwise yes, it'll be 
all downside. And 4/4 vs 3/1 isn't really a fair comparison ... 4/4 is
designed for bigboxen, so 4/4 vs 2/2 would be better, IMHO. People have
said before that DB performance can increase linearly with shared area
sizes (for some workloads), so that'd bring you a 100% or so increase
in performance for 4/4 to counter the loss.

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/