From: Andrea Arcangeli <andrea@suse.de>
To: Lorenzo Allegrucci <lenstra@tiscalinet.it>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.12aa1 [was Re: 2.4.11aa1 [was Re: 2.4.11pre6aa1]]
Date: Fri, 12 Oct 2001 07:06:55 +0200 [thread overview]
Message-ID: <20011012070655.I714@athlon.random> (raw)
In-Reply-To: <20011010051104.F726@athlon.random> <20011009205516.F724@athlon.random> <20011010051104.F726@athlon.random> <20011011123231.C714@athlon.random> <3.0.6.32.20011011215917.01e78210@pop.tiscalinet.it>
In-Reply-To: <3.0.6.32.20011011215917.01e78210@pop.tiscalinet.it>; from lenstra@tiscalinet.it on Thu, Oct 11, 2001 at 09:59:17PM +0200
On Thu, Oct 11, 2001 at 09:59:17PM +0200, Lorenzo Allegrucci wrote:
> Linux-2.4.11:
>
> lenstra:~/src/qsort> time ./qsbench -n 90000000 -p 1 -s 140175100
> seed = 140175100
> 71.020u 1.650s 2:20.74 51.6% 0+0k 0+0io 10652pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 90000000 -p 1 -s 140175100
> seed = 140175100
> 71.070u 1.650s 2:21.51 51.3% 0+0k 0+0io 10499pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 90000000 -p 1 -s 140175100
> seed = 140175100
> 70.790u 1.670s 2:21.01 51.3% 0+0k 0+0io 10641pf+0w
>
> lenstra:~/src/qsort> time ./qsbench -n 9000000 -p 10 -s 140175100
> 63.500u 1.800s 1:34.06 69.4% 0+0k 0+0io 8836pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 9000000 -p 10 -s 140175100
> 63.020u 1.470s 1:20.22 80.3% 0+0k 0+0io 6394pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 9000000 -p 10 -s 140175100
> 63.130u 1.520s 1:12.21 89.5% 0+0k 0+0io 5676pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 9000000 -p 10 -s 140175100
> 62.820u 1.560s 1:12.61 88.6% 0+0k 0+0io 5433pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 9000000 -p 10 -s 140175100
> 63.070u 1.560s 1:14.83 86.3% 0+0k 0+0io 5811pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 9000000 -p 10 -s 140175100
> 63.160u 1.650s 1:17.84 83.2% 0+0k 0+0io 6036pf+0w
>
> lenstra:~/src/qsort> time ./qsbench -n 45000000 -p 2 -s 140175100
> 71.290u 2.010s 1:50.11 66.5% 0+0k 0+0io 10462pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 45000000 -p 2 -s 140175100
> 71.490u 2.220s 1:49.62 67.2% 0+0k 0+0io 11413pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 45000000 -p 2 -s 140175100
> 71.280u 2.360s 1:54.79 64.1% 0+0k 0+0io 11110pf+0w
>
>
>
> Linux-2.4.12-aa1:
>
> lenstra:~/src/qsort> time ./qsbench -n 90000000 -p 1 -s 140175100
> seed = 140175100
> 71.420u 2.110s 2:49.01 43.5% 0+0k 0+0io 16110pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 90000000 -p 1 -s 140175100
> seed = 140175100
> 70.960u 1.850s 2:45.05 44.1% 0+0k 0+0io 15463pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 90000000 -p 1 -s 140175100
> seed = 140175100
> 70.760u 1.980s 2:45.61 43.9% 0+0k 0+0io 15595pf+0w
>
> lenstra:~/src/qsort> time ./qsbench -n 9000000 -p 10 -s 140175100
> 64.020u 1.940s 1:38.76 66.7% 0+0k 0+0io 10206pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 9000000 -p 10 -s 140175100
> 64.190u 1.410s 1:16.98 85.2% 0+0k 0+0io 6796pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 9000000 -p 10 -s 140175100
> 63.530u 1.520s 1:13.51 88.4% 0+0k 0+0io 5274pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 9000000 -p 10 -s 140175100
> 63.980u 1.370s 1:16.53 85.3% 0+0k 0+0io 6456pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 9000000 -p 10 -s 140175100
> 63.640u 1.680s 1:16.38 85.5% 0+0k 0+0io 6189pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 9000000 -p 10 -s 140175100
> 63.720u 1.500s 1:15.33 86.5% 0+0k 0+0io 5777pf+0w
>
> lenstra:~/src/qsort> time ./qsbench -n 45000000 -p 2 -s 140175100
> 72.810u 2.010s 1:58.16 63.3% 0+0k 0+0io 14220pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 45000000 -p 2 -s 140175100
> 71.700u 2.290s 1:58.68 62.3% 0+0k 0+0io 13803pf+0w
> lenstra:~/src/qsort> time ./qsbench -n 45000000 -p 2 -s 140175100
> 72.440u 2.220s 1:56.13 64.2% 0+0k 0+0io 12911pf+0w
ok, it probably swapouts a little slower during the most heavy run,
that's pretty much intentional with the page-layer write throttling. The
little slowdown in swapout performance in the most heavy swapout
testcase should provide a much smoother responsiveness to the system
during the load that is more important than pure swap bandwith (if the
system feels unresponsive during the swap storm is much worse than the
pure speed of the allocations). In my interactive tests it was taking
more than 2 minutes to startup netscape during very heavy swapout
storms. With this new code it took more than 1 minute showing a
sensible improvement in the understanding of the working set and the
swap beandwith decrease doesn't seem significant given that the cpu load
decreased of 8% (so again in-core applications could make more
progress).
thanks for the feedback Lorenzo!
Andrea
prev parent reply other threads:[~2001-10-12 5:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-09 18:55 2.4.11pre6aa1 Andrea Arcangeli
2001-10-10 3:11 ` 2.4.11aa1 [was Re: 2.4.11pre6aa1] Andrea Arcangeli
2001-10-11 10:32 ` 2.4.12aa1 [was Re: 2.4.11aa1 [was Re: 2.4.11pre6aa1]] Andrea Arcangeli
2001-10-11 19:59 ` Lorenzo Allegrucci
2001-10-12 5:06 ` Andrea Arcangeli [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011012070655.I714@athlon.random \
--to=andrea@suse.de \
--cc=lenstra@tiscalinet.it \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox