linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Scott Kaplan <sfkaplan@cs.amherst.edu>
To: Mel <mel@csn.ul.ie>
Cc: linux-mm@kvack.org
Subject: Re: [PATCH] rmap 14
Date: Wed, 21 Aug 2002 14:39:06 -0400	[thread overview]
Message-ID: <4646A0E8-B535-11D6-A545-000393829FA4@cs.amherst.edu> (raw)
In-Reply-To: <Pine.LNX.4.44.0208211708450.29496-100000@skynet>

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

On Wednesday, August 21, 2002, at 12:28 PM, Mel wrote:

> On Wed, 21 Aug 2002, Scott Kaplan wrote:
>
>> What papers are those?  We all try to keep up with the literature, but if
>> there's something that I've missed here, I'd love to know about it.
>
> For a start, I'm not reviewing litrature actively so I'm not up to date on
> papers at all, nor am I willing to get involved in a I Know More Papers
> Than You discussion here.

I wasn't trying to get into a contest.  When someone mentioned that they 
know of papers to support an interesting position, I just want to know 
what those papers are, as the resulting list may include some that I haven'
t seen.

> One that comes to mind I think was called Adaptive Page Replacement Based
> on Memory Reference Behaviour or something very similar to that name. I
> think it had something on collecting trace reference that was based on
> real programs.

Are you thinking of the paper on the SEQ replacement policy by Glass and 
Cao?  If so, be skeptical of their trace gathering methods.  They gathered 
and reduced their traces in an ad-hoc manner that left some serious 
limitations to the use of those traces.  They also don't mention reference 
behavior modeling at all; they simply gathered some traces based on the 
spec95 benchmark, tested their new page replacement policy, and showed the 
results.

> In Search of a Better Malloc I *think* had something on traces but it
> depended on synthetic traces for information that had some sort of uniform
> distribution. It struck me as been not particularly reliable but it was a
> method that appeared to be used in a number of other papers.

> I'm am almost definite that "Dynamic Storage Allocation, A Critical
> Review" has a section on traces and how they tended to be synthetic or
> generated by small custom programs and why this was a bad thing. I believe
> it talked briefly about how synthetic traces were used because they were
> really easy to produce, not because they were useful. Still, it highlights
> the problem of using predictable data.

Also try Johnstone and Wilson, ``The Memory Fragmentation Problem: Solved?
'' (International Symposium on Memory Management '98) -- it's a later 
version of that same work.  I'm unfamiliar with the second paper you 
mentioned, but you should also see Zorn and Grunwald, ``Evaluating Models 
of Memory Allocation'' (U. Colorado tech report from '92), in which they 
claim that many simple models are good, but none good enough to synthesize 
a full system workload.

For reference behavior, an old citation, but perhaps a useful one, is 
Richard Carr's ``Virtual Memory Management'' (Ph.D. thesis, 1984 or 
thereabouts), in which he address a number of approaches to modeling, 
their shortcomings, and then presents a new one that is probably better, 
but goes unvalidated against real program behavior.

> By and large, I found that papers on memory allocators tend to
> focus on trace data and it's usefulness more than page replacement papers
> did.  I could be wrong here though but don't quote me on that.

That's likely true.  Use of models for reference traces seemed to die out 
about 15 years ago, as gathering real reference traces became more 
feasible (larger storage, faster chips for compression, etc.)

Scott
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iD8DBQE9Y95O8eFdWQtoOmgRAhOtAJ4s4tzA184T3UnxB37R+cxKsAcYNwCcCS0q
LVw0VCDFUy47oamDjWtaz54=
=1pLE
-----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-mm.org/

  reply	other threads:[~2002-08-21 18:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-16  2:07 Rik van Riel
2002-08-16  2:21 ` Bill Huey
2002-08-16 21:02   ` Mel
2002-08-16 21:29     ` Scott Kaplan
2002-08-16 23:02       ` Mel
2002-08-19 19:05         ` Scott Kaplan
2002-08-19 21:04           ` Mel
2002-08-20 18:41             ` Stephen C. Tweedie
2002-08-21 18:03               ` Mel
2002-08-21 15:05             ` Scott Kaplan
2002-08-21 16:28               ` Mel
2002-08-21 18:39                 ` Scott Kaplan [this message]
2002-08-19 19:50         ` Daniel Phillips
2002-08-19 21:19           ` Mel
2002-08-19 21:38             ` Daniel Phillips
2002-08-19 18:04       ` Daniel Phillips

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=4646A0E8-B535-11D6-A545-000393829FA4@cs.amherst.edu \
    --to=sfkaplan@cs.amherst.edu \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    /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