lkml.org 
[lkml]   [2002]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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]
\
 
 \ /
  Last update: 2005-03-22 13:27    [W:0.042 / U:1.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site