RE: objrmap-core-1 (rmap removal for file mappings to avoid 4:4 in <=16G machines)

From: Bond, Andrew
Date: Tue Mar 09 2004 - 12:45:04 EST




> -----Original Message-----
> From: linux-kernel-owner@xxxxxxxxxxxxxxx [mailto:linux-kernel-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Martin J. Bligh
> Sent: Tuesday, March 09, 2004 12:23 PM
> To: Andrea Arcangeli; Ingo Molnar
> Cc: Arjan van de Ven; Linus Torvalds; Andrew Morton; linux-
> kernel@xxxxxxxxxxxxxxx
> Subject: Re: objrmap-core-1 (rmap removal for file mappings to avoid
4:4
> in <=16G machines)
>
> > what is your point, that OASB is a worthless workload and the only
thing
> > that matters is TPC-C? Maybe you should discuss your point with
Oracle
> > not with me, since I don't know what the two benchmarks are doing
> > differently. TCP-C was tested too of course, but maybe not in 32G
boxes,
> > frankly I thought OASB was harder than TCP-C, as I think Martin
> > mentioned too two days ago.
>
> OASB seems harder on the VM than TPC-C, yes. It seems to create
thousands
> of processes, and fill the user address space up completely as well
(2GB
> shared segments or whatever).
>
> M.
>

Both the OASB and TPC-C workloads put pressure on the VM subsystem, but
in different ways.

The OASB environment has a small (compared to TPC-C) shared memory area,
but 1000's of Oracle user processes will be created that attach to this
shared memory area. The goal here is to push the maximum amount of
users onto the server.

The TPC-C environment will have a very large shared memory area
(typically the maximum a machine will allow) that may generate a large
number of vmas. However, there are very few (may be few hundred) Oracle
users processes.

Experience has been that the OASB benchmarks will tend to push VM into
system lockup conditions more than TPC-C.

Andy
-
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/