lkml.org 
[lkml]   [1998]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: page_alloc strange mask += mask
From
Date
Andrea Arcangeli <arcangeli@mbox.queen.it> writes:

> On 6 Aug 1998, Zlatko Calusic wrote:
>
> >Patched with this, your kernel will still age named pages, but will do
> >that harder, so page cache pages will be reused faster and less pages
> >will get swapped out.
>
> Yes, seems to help a bit (I have not produced numbers). There' s still a
> stall every time kswapd swapout things, but it seems rasonable that kswapd
> swapout things (unlike 2.0), because the memory used by a lot of programs
> can' t be accessed more recently than the page cache (even if we force the
> cache to become older faster).
>

Yep, that's mine opinion, too.

I even made some benchmarks (that were sent to linux-mm@kvack.org),
and I'm resending them here, if anybody's interested. It would be nice
to compare results from different machines, and hear other people
opinion on this change. Original text below.

----------------------------------------------------------------------
Yes, this is on .110.

Benchmarking methodology: compile kernel, reboot, fire up XDM, few
xterms, Xemacs and Netscape. In one xterm vmstat 10, in another copy
800MB worth of .mp3s :) to /dev/null (nothing special changes if I
copy them to another directory)

Official kernel:
1 x age_page() in shrink_mmap():

procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
1 0 0 0 6832 4292 22740 0 0 182 15 220 155 25 9 66
0 0 0 0 6860 4292 22744 0 0 0 5 112 10 0 0 100
1 0 0 428 1380 1964 31260 0 43 5579 13 221 202 1 22 77
1 0 0 2472 1428 1964 33256 10 209 5742 53 232 211 2 24 75
1 0 0 5200 3500 1988 33928 5 273 6017 70 236 216 2 25 73
1 0 0 7012 2940 1964 36292 6 181 6318 46 243 224 2 27 71
1 0 0 11036 1084 1964 42168 6 402 5910 101 240 212 1 27 72
1 0 0 12572 3832 2028 40900 6 154 5939 39 239 211 1 23 76
1 0 0 14288 11336 1964 35180 10 172 5863 44 233 209 1 24 75
1 0 0 17484 1188 1964 48552 29 320 5076 81 229 189 1 23 76
1 0 0 18588 10640 1964 40176 42 111 4668 29 217 187 1 18 81
1 0 0 21988 1576 1964 52636 43 342 5434 86 240 204 1 22 77
1 0 0 23524 13676 1964 42076 47 154 5652 39 236 222 1 22 77
1 1 0 23812 1284 1992 54728 41 31 5915 9 234 230 1 25 74
1 0 0 24076 24324 2028 31916 40 30 6106 8 239 226 1 24 75
1 0 0 24092 16064 2028 40188 48 7 5869 3 235 226 1 22 77
0 0 0 24020 1540 2000 54724 30 0 2356 1 162 114 0 11 89
0 0 0 23980 1536 2000 54688 8 0 2 0 104 19 0 0 100

24MB outswapped, lots of swapouts and swapins!!!. There would be much
more swap activity if I were actually using Netscape or XEmacs during
I/O, but in both test I didn't! I forgot to put "time" before cp :(,
but... 15 lines x 10 sec = cca 150 seconds to copy files. Also, notice
that I'm not memory starved (starting with cca 7 + 4 + 23 = 34 MB for
caches to use). In the last minute, system practically outswapped
everything it could, so it started to fight for every other page
effectively losing time (~30 pages out, ~40 pages in, every second).
Too bad. :(


Patched with small patch I posted:
3 x age_page() in shrink_mmap():

procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
1 0 0 0 7072 4292 22768 0 0 172 15 217 153 23 9 68
0 0 0 0 7048 4292 22736 0 0 0 2 109 11 0 0 100
1 0 0 76 1044 1964 31444 0 8 5899 4 228 219 1 20 79
1 0 0 116 6076 1964 26432 0 4 6665 2 243 241 2 27 71
1 0 0 132 6492 2028 25980 0 2 6723 1 239 238 1 25 75
1 0 0 488 6816 2028 26016 0 36 6671 10 240 233 1 25 74
1 0 0 1288 1240 1964 32460 0 80 6163 21 232 220 1 23 76
1 0 0 2152 1536 1964 33028 0 86 6234 22 233 223 1 24 76
1 0 0 3008 1384 1964 34032 0 86 6313 22 235 229 1 22 77
1 0 0 3084 1488 1964 34008 0 8 6135 3 229 223 1 22 77
1 0 0 4816 1128 1964 36096 0 173 6778 44 247 237 2 25 73
1 0 0 5912 1172 1964 37152 0 110 7103 28 252 252 1 29 70
1 0 0 6904 1536 1964 37780 0 99 7247 26 250 252 1 27 72
1 0 0 8348 3704 2028 36988 0 144 7095 37 255 243 1 25 73
0 0 0 9164 14980 2028 26608 1 82 3278 22 173 120 1 13 86
0 0 0 9164 14980 2028 26608 0 0 0 0 102 6 0 0 100

First thing to notice is only 10MB on swap (good). Second, and more
important, system was *not* swapping things in at all, because only
pages that really belonged to swap (unneeded) were swapped out.
Copying finished in 13 x 10 = ~130 seconds. Conclusion: better I/O
performance, better feel when using applications (I didn't have to
wait for Netscape or XEmacs to come from swap when I started to use
them, for real).

I was very carefull to do exactly the same sequence in both tests!
I think it is obvious from the first line of those vmstat reports.

Anything I forgot to test? :)
----------------------------------------------------------------------

Regards,
--
Posted by Zlatko Calusic E-mail: <Zlatko.Calusic@CARNet.hr>
---------------------------------------------------------------------
The world is coming to an end. Please log off.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.040 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site