[lkml]   [1999]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] arca-vm-19 [Re: Results: Zlatko's new vm patch]
> On Wed, 13 Jan 1999, Andrea Arcangeli wrote:
> > I produced a new arca-vm-19. I would like if you could try it. I don't
> It seems that the better algorithm I am be able to invent is been the
> growing_swap_cache one (the one in arca-vm-16). Steve could you try this
> new patch (arca-vm-20) against real 2.2.0-pre7? I think that it should be
> still better than arca-vm-16 + SWAP_CLUSTER_MAX=512.
> If it will be not very good could you do:
> echo 8 2 4 512 512 512 > /proc/sys/vm/pager
> and try again? (such numbers should be the same of setting
> SWAP_CLUSTER_MAX in arca-vm-16, but as default only the max_async_pages is
> set to 512 because I think it's been the only one that made a difference).
> If this will be not the best again you could apply the filemap.c patch I
> sent you in the last email (the one that return to put the shrink_mmap()
> weight exponential increasing in function of priority) and try again?

Hi Andrea!

I tested vm20 against bare 2.2.0-pre7 and it doesn't do the job 8*(

The system is a little bit more responsive while doing a 12G mke2fs
now only taking about 10-20 seconds ;-( to bring up another kvt
compared to end of mke2fs without vm20.

But compared to < 2.2.0 VM this is about at least 10-20!!! times slower.

The system (2*PII/350, 256M RAM) swaps out 30MB (kvts etc.) for _no_
obvious reason with paging rates up to > 100/s ?!

I don't like 1 process eating up main memory for buffer/page cache
_and_ thereby causing swaping out inactive others.

Other testers reported the same effect, if the system runs
for some days under medium load.

/proc,sys/vm/{buffermemm, pagecache} are gone now because they haven't been
used any longer, but at least i liked them.

Why not keep that interface and the thereby implied limits in the kernel
VM to allow the admin to set them to 100% if he likes to?

Sorry if this sounds too bad, but to my opinion this behaviour is an absolute
_must_ change before the final 2.2 release!

Keep up the good work,



Systemmanagement Entwicklungsbereich 2 Deutsche Telekom AG
Entwicklungszentrum Darmstadt
Heinz Mauelshagen Otto-Roehm-Strasse 71c
Postfach 10 05 41 64205 Darmstadt
+49 6151 886-425

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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