Messages in this thread | | | Date | Wed, 10 Jul 2002 15:18:08 -0700 | From | Hanna Linder <> | Subject | Re: scalable kmap (was Re: vm lock contention reduction) (fwd) |
| |
--On Wednesday, July 10, 2002 09:15:15 -0700 "Martin J. Bligh" <Martin.Bligh@us.ibm.com> wrote:
> > Updated patch below ... > > > arch/i386/kernel/i386_ksyms.c | 5 ++ > arch/i386/lib/usercopy.c | 10 +++++ > arch/i386/mm/fault.c | 71 +++++++++++++++++++++++++++++++++++ > fs/exec.c | 60 +++++++++++++++++++++--------- > include/asm-i386/highmem.h | 5 ++ > include/asm-i386/kmap_types.h | 3 + > include/asm-i386/processor.h | 2 + > include/asm-ppc/kmap_types.h | 1 > include/asm-sparc/kmap_types.h | 1 > include/asm-x86_64/kmap_types.h | 1 > include/linux/highmem.h | 80 ++++++++++++++++++++++++++++++++++++++++ > include/linux/sched.h | 5 ++ > mm/filemap.c | 11 +++-- > 13 files changed, 232 insertions(+), 23 deletions(-)
Andrew and Martin,
I ran this updated patch on 2.5.25 with dbench on the 8-way with 4 Gb of memory compared to clean 2.5.25. I saw a significant improvement in throughput about 15% (averaged over 5 runs each). Included is the pretty picture (akpm-2525.png) the data that picture came from (akpm-2525.data) and the raw results of the runs with min/max and timing results (2525akpmkmaphi and 2525clnhi). I believe the drop at around 64 clients is caused by memory swapping leading to increased disk accesses since the time increased by 200% in direct correlation with the decreased throughput.
Hanna
[unhandled content-type:image/png][unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream] | |