Re: 2.5.38-mm2 dbench $N times

From: Andrew Theurer <habanero@us.ibm.com>
To: "Martin J. Bligh" <mbligh@aracnet.com>,
	Andrew Morton <akpm@digeo.com>,
	William Lee Irwin III <wli@holomorphy.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.5.38-mm2 dbench $N times
Date: Wed, 25 Sep 2002 16:05:08 -0500	[thread overview]
Message-ID: <200209251605.08477.habanero@us.ibm.com> (raw)
In-Reply-To: <253480000.1032987442@flay>

On Wednesday 25 September 2002 3:57 pm, Martin J. Bligh wrote:
> > Pretty sure each dbench child does it's own write/read to only it's own
> > data. There is no sharing that I am aware of between the processes.
>
> Right, but if the processes migrate easily, there's still no CPU locality.
> Bill, do you want to try binding 1/32 of the processes to each CPU, and see
> if that makes your throughput increase?

Any stats to track migration over <x> time?  Would be intersting to see this 
in some sort of /proc/pid maybe?

> > How about running in tmpfs to avoid any disk IO at all?
>
> As far as I understand it, that won't help - we're operating out of
> pagecache anyway at this level, I think.

at dbench 512, that's about 512*20MB, 10GB (not 100% sure on that 20MB 
figure).  Have we hit a threshold at which this stuff gets written to disk?

> > Also, what's the policy for home node assignment on fork?  Are all of
> > these children getting the same home node assingnment??
>
> Policy is random - the scheduler lacks any NUMA comprehension at the
> moment. The numa sched mods would probably help a lot too.

Oops, confusing this run with the numa sched stuff earlier.

Andrew Theurer