Messages in this thread |  | | | From | Andrew Theurer <> | | Subject | Re: 2.5.38-mm2 dbench $N times | | Date | Wed, 25 Sep 2002 16:05:08 -0500 |
| |
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 - 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/
|  |