From: Scott F. Kaplan <sfkaplan@cs.amherst.edu>
To: linux-mm@kvack.org
Subject: Re: VM tuning through fault trace gathering [with actual code]
Date: Tue, 26 Jun 2001 10:02:26 -0400 [thread overview]
Message-ID: <01062610022607.01124@spigot> (raw)
In-Reply-To: <m28zigi7m4.fsf@boreas.yi.org.>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John Fremlin <vii@users.sourceforge.net> wrote:
> Rik van Riel <riel@conectiva.com.br> writes:
> > Sounds like a cool idea. One thing you should keep in mind though
> > is to gather traces of the WHOLE SYSTEM and not of individual
> > applications.
Not to look a gift horse in the mouth, but the ability to trace selectively
either the whole system OR an individual application would be useful.
Certainly whole system traces would be new, as individual process traces can
be gathered with other tools (although I don't know of one available on Linux
- -- I'm stuck using ATOM under Alpha/Tru64.)
> In the current patch all pagefaults are recorded from all sources. I'd
> like to be able to catch read(2) and write(2) (buffer cache stuff) as
> well but I don't know how . . . .
Also a great idea. Someone who works on the filesystem end of the kernel
should be able to add support for this kind of thing without much trouble,
don't you think?
> Of course! It is important not to regard each thread group as an
> independent entity IMHO (had a big old argument about this).
Yes, I was the other side of that argument! :-) I'll still contend that,
tracking references for each process is better than tracking it only for the
whole system, and tracking references for each thread might be better still.
When you track references from the whole-system view alone, pathological
reference behavior of one process gets mixed in with other processes, making
it impossible to identify that the one process should have its memory managed
in a manner different from the others. Grouping together behaviors just
smooths their features. Separating them offers an opportunity to identify
anomolies, and anomolies are opportunities for better memory management.
Scott
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7OJX18eFdWQtoOmgRAmniAKCTFGVJmgMOXJWiHfA+UxVUiT37zQCfZywy
bRYZKRymeXfjhh6wX2SZb6I=
=5TTZ
-----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/
next prev parent reply other threads:[~2001-06-26 14:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-25 15:26 John Fremlin
2001-06-25 17:57 ` Rik van Riel
2001-06-25 21:15 ` John Fremlin
2001-06-26 14:02 ` Scott F. Kaplan [this message]
2001-06-26 19:29 ` John Fremlin
2001-06-26 0:53 ` Marcelo Tosatti
2001-06-26 12:54 ` John Fremlin
2001-06-26 13:52 ` Marcelo Tosatti
2001-06-26 15:38 ` John Fremlin
2001-06-27 10:09 ` Marcelo Tosatti
2001-06-27 12:47 ` Scott F. Kaplan
2001-06-27 13:51 ` Marcelo Tosatti
2001-06-27 16:05 ` John Fremlin
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=01062610022607.01124@spigot \
--to=sfkaplan@cs.amherst.edu \
--cc=linux-mm@kvack.org \
/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