Re: Fwd: Re: [PATCH][RFC] appling preasure to icache and dcache

[sfkaplan@cs.amherst.edu]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.  Just a few thoughts that I hope will be useful.

On Tue, 3 Apr 2001, Ed Tomlinson wrote:

> On Tuesday 03 April 2001 17:35, Rik van Riel wrote:
> > On Tue, 3 Apr 2001, Ed Tomlinson wrote:
> > > On Tuesday 03 April 2001 11:03, Benjamin Redelings I wrote:
> > > > Hi, I'm glad somebody is working on this!  VM-time seems like a pretty
> > > > useful concept.

The notion of VM time has been kicking around for about 10 years.  I
picked it up from my graduate advisor, and so it has worked its way
into a number of research ideas.  This approach to measuring VM time
is an interesting one, and slightly different from the way in which
I've approached it.

> > > Think it might be useful for detecting trashing too.  If vmtime is
> > > made to directly relate to the page allocation rate then you can do
> > > something like this.  Let K be a number intially representing 25% of
> > > ram pages. Because vmtime is directly releated to allocation rates its
> > > meanful to subtract K from the current vmtime.  For each swapped out
> > > page, record the current vmtime.  Now if the recorded vmtime of the
> > > page you are swapping in is greater than vmtime-K increment A
> > > otherwise increment B. If A>B we are thrashing.  We decay A and B via
> > > kswapd.  We adjust K depending on the swapping rate.  Thoughts?

A couple of thoughts:

1) Nit-pick:  You mean "thrashing", not "trashing", right?  Or is
   there a definition of "trashing" with which I'm not familiar?

2) There's a difference between detecting that the VM system is
   evicting pages and then using them shortly thereafter, and
   detecting thrashing.  Your description above may detect the former
   case -- It's something that AIX did many years ago (or so I'm told
   by some IBM researchers), and it's a simplified case of what EELRU,
   an algorithm I was part of developing, detects.  It's a useful
   case, because it likely indicates a loop-like reference pattern
   over slightly more memory than is available, forcing LRU to
   degenerate into FIFO.

   However, it is not necessarily detecting thrashing.  "Heavy paging"
   and "thrashing" aren't necessarily the same thing.  Thrashing
   occurs when so much time is spent servicing page faults that the
   CPU rarely has any work to do (i.e. no ready processes to run.)  It
   is easily possible to thrash without tripping the detection
   mechanism that you're describing.

3) Your detection mechanism seems as though it would detect something
   interesting.  However, I don't understand the response that you
   describe.  Decaying A and B seems fine, and an important part of
   accurate detection based on recent behavior.  However, why adjust
   K?  That doesn't seem to solve the problem.  The process may still
   continue to reference pages evicted not long ago.  Addressing
   this case reqires either a larger memory allocation (somehow or
   other) or a modification of the replacement policy (some non-LRU
   evictions).  If you adjust K to be smaller, than you're just less
   likely to trip the detection mechanism.  If you make K larger, it
   becomes more likely.  You'll still have the same problem.

I hope these comments help.  More likely than not, I've misunderstood
what you're proposing.  If so, please let me know what I've botched.

Scott Kaplan
sfkaplan@cs.amherst.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6yxZH8eFdWQtoOmgRAkggAJ4pY9eWIpl55yQteuYgD4eraCTk5wCgivNp
etqUh9afUf2cZ7zA1dAVf30=
=YGhN
-----END PGP SIGNATURE-----

--
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.eu.org/Linux-MM/