From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 06 Feb 2006 18:30:23 +0900 From: IWAMOTO Toshihiro Subject: Re: [PATCH 6/9] clockpro-clockpro.patch In-Reply-To: <1138958705.5450.9.camel@localhost.localdomain> References: <20051230223952.765.21096.sendpatchset@twins.localnet> <20051230224312.765.58575.sendpatchset@twins.localnet> <20051231002417.GA4913@dmt.cnet> <1136028546.17853.69.camel@twins> <20060105094722.897C574030@sv1.valinux.co.jp> <20060106090135.3525D74031@sv1.valinux.co.jp> <20060124063010.B85C77402D@sv1.valinux.co.jp> <20060124072503.BAF6A7402F@sv1.valinux.co.jp> <1138958705.5450.9.camel@localhost.localdomain> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20060206093023.E4F227402D@sv1.valinux.co.jp> Sender: owner-linux-mm@kvack.org Return-Path: To: Peter Zijlstra Cc: IWAMOTO Toshihiro , Rik van Riel , Peter Zijlstra , Marcelo Tosatti , linux-mm@kvack.org, Andrew Morton , Christoph Lameter , Wu Fengguang , Nick Piggin , Marijn Meijles List-ID: Hi, At Fri, 03 Feb 2006 10:25:04 +0100, Peter Zijlstra wrote: > > On Tue, 2006-01-24 at 16:25 +0900, IWAMOTO Toshihiro wrote: > > Environment: Dell 1850 4GB EM64T CPUx2 HT disabled, x86_64 kernel > > Kernel 1: linux-2.6.15-rc5 > > Kernel 2: linux-2.6.15-rc5 + clockpro patch posted in 2005/12/31 > > Kernel 3: linux-2.6.15-rc5 + clockpro patch posted in 2005/12/31 + > > modification to disable page cache usage from ZONE_DMA > > (to rule out possible zone balancing related problem) > > Kernel 1 and 2 were booted with "mem=1008m", Kernel 3 was booted with > > "mem=1024m". > > > > The test program: 2read.c (attached below) > > 2read.c repeatedly reads from two files zero and zero2. > > Command line arguments specify the ranges to be read. (See the > > code for detail) > > It prints the number of read operations/2 every 5 seconds and > > terminates in 5 minutes. > > > > $ cc -O 2read.c > > $ ls -l zero* > > -rw-r--r-- 1 toshii users 1073741824 2006-01-13 17:27 zero > > -rw-r--r-- 1 toshii users 1572864000 2006-01-20 18:20 zero2 > > > > (with Kernel 1) > > $ for n in 100 200 300 400 500; do > > > ./a.out -n $n $((1100-$n)) > /tmp/2d.$n ; done > > (with Kernel 2) > > $ for n in 100 200 300 400 500; do > > > ./a.out -n $n $((1100-$n)) > /tmp/2d.c.$n ; done > > (with Kernel 3) > > $ for n in 100 200 300 400 500; do > > > ./a.out -n $n $((1100-$n)) > /tmp/2d.c.nodma.$n ; done > > > > The table below is the last numbers printed by the test program > > ((number of reads)/2 in 5 minutes). Clockpro (with or without the > > ZONE_DMA modification) is always slower with one exception, and > > the slowdown can be as large as 42-54%. > > > > I've put the complete data and some generated figures at > > http://people.valinux.co.jp/~iwamoto/clockpro-20051231/ > > > > n Kernel 1 Kernel 2 Kernel 3 > > ====================================== > > 100 373600 298720 395818 > > 200 385639 272749 272166 > > 300 371047 243734 262370 > > 400 367691 213974 169714 > > 500 147130 126284 103038 > > > > Iwamoto-San, > Could you test again with my latest patches found at: > http://programming.kicks-ass.net/kernel-patches/page-replace/2.6.16-rc1-3/ I've built kernels with CONFIG_MM_POLICY_CLOCKPRO enabled and disabled and ran the same tests. n disabled enabled ======================== 100 366962 392283 200 342172 393087 300 339325 309595 400 230029 283340 500 121352 132298 The non-clockpro version (left) has got slower in n >= 400, and the clockpro version has got faster in n <= 400. The clockpro version is still slower than the "kernel 1" for n=300,400. There seem to be a few percents of measurement variances, so I shouldn't judge something from small differences in values. > esp. the last patch in the series: > http://programming.kicks-ass.net/kernel-patches/page-replace/2.6.16-rc1-3/kswapd-writeout-wait.patch This change doesn't seem to be related to clockpro. I wonder if (and why) it is significant. > which is what I needed to do in order to fix some regressions found with > your test case. It seems to work on my system, although it is admittedly > quite a bit smaller than your machine. I haven't tried but it should be possible to create similar workloads by scaling down the arguments to 2read.c. BTW, I made some detailed measurments with older kernels. I'll mail the results later. -- IWAMOTO Toshihiro -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org