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

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 also don't have any of the papers here and I don't have the time to look
at the moment because I'm writing the docs for vmregress 0.6.  Three come
to mind but they are all old papers but the principles are the same or at
least should be and semi relevant to collecting trace data for VM Regress.

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.  It wasn't under Linux though, it was Solaris I believe so
not of direct use to us here.

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.

There are others but I have a bad memory for remembering individual
papers. 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. By and
large, this is off-topic, so I'll shut up now.

-- 
Mel Gorman
MSc Student, University of Limerick
http://www.csn.ul.ie/~mel


--
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 16:28 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 [this message]
2002-08-21 18:39                 ` Scott Kaplan
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=Pine.LNX.4.44.0208211708450.29496-100000@skynet \
    --to=mel@csn.ul.ie \
    --cc=linux-mm@kvack.org \
    --cc=sfkaplan@cs.amherst.edu \
    /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