From: Terry Lambert <tlambert2@mindspring.com>
To: Matt Dillon <dillon@earth.backplane.com>
Cc: Rik van Riel <riel@conectiva.com.br>,
Charles Randall <crandall@matchlogic.com>,
Roger Larsson <roger.larsson@norran.net>,
arch@FreeBSD.ORG, linux-mm@kvack.org, sfkaplan@cs.amherst.edu
Subject: Re: on load control / process swapping
Date: Thu, 17 May 2001 22:58:37 -0700 [thread overview]
Message-ID: <3B04BA0D.8E0CAB90@mindspring.com> (raw)
In-Reply-To: <200105161754.f4GHsCd73025@earth.backplane.com>
Matt Dillon wrote:
> Terry's description of 'ld' mmap()ing and doing all
> sorts of random seeking causing most UNIXes, including
> FreeBSD, to have a brainfart of the dataset is too big
> to fit in the cache is true as far as it goes, but
> there really isn't much we can do about that situation
> 'automatically'. Without hints, the system can't predict
> the fact that it should be trying to cache the whole of
> the object files being accessed randomly. A hint could
> make performance much better... a simple madvise(...
> MADV_SEQUENTIAL) on the mapped memory inside LD would
> probably be beneficial, as would madvise(... MADV_WILLNEED).
I don't understand how either of those things could help
but make overall performance worse.
The problem is the program in question is seeking all
over the place, potentially multiple times, in order
to avoid building the table in memory itself.
For many symbols, like "printf", it will hit the area
of the library containing their addresses many, many
times.
The problem in this case is _truly_ that the program in
question is _really_ trying to optimize its performance
at the expense of other programs in the system.
The system _needs_ to make page-ins by this program come
_at the expense of this program_, rather than thrashing
all other programs out of core, only to have the quanta
given to these (now higher priority) programs used to
thrash the pages back in, instead of doing real work.
The problem is what to do about this badly behaved program,
so that the system itself doesn't spend unnecessary time
undoing its evil, and so that other (well behaved) programs
are not unfairly penalized.
Cutler suggested a working set quota (first in VMS, later
in NT) to deal with these programs.
-- Terry
--
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/
next prev parent reply other threads:[~2001-05-18 5:58 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-16 15:17 Charles Randall
2001-05-16 17:14 ` Matt Dillon
2001-05-16 17:41 ` Rik van Riel
2001-05-16 17:54 ` Matt Dillon
2001-05-16 19:59 ` Rik van Riel
2001-05-16 20:41 ` Matt Dillon
2001-05-18 5:58 ` Terry Lambert [this message]
2001-05-18 6:20 ` Matt Dillon
2001-05-18 10:00 ` Andrew Reilly
2001-05-18 13:49 ` Jonathan Morton
2001-05-19 2:18 ` Rik van Riel
2001-05-19 2:56 ` Jonathan Morton
2001-05-16 17:57 ` Alfred Perlstein
2001-05-16 18:01 ` Matt Dillon
2001-05-16 18:10 ` Alfred Perlstein
[not found] <OF5A705983.9566DA96-ON86256A50.00630512@hou.us.ray.com>
2001-05-18 20:13 ` Jonathan Morton
-- strict thread matches above, loose matches on Subject: below --
2001-05-07 21:16 Rik van Riel
2001-05-07 22:50 ` Matt Dillon
2001-05-07 23:35 ` Rik van Riel
2001-05-08 0:56 ` Matt Dillon
2001-05-12 14:23 ` Rik van Riel
2001-05-12 17:21 ` Matt Dillon
2001-05-12 21:17 ` Rik van Riel
2001-05-12 23:58 ` Matt Dillon
2001-05-13 17:22 ` Rik van Riel
2001-05-15 6:38 ` Terry Lambert
2001-05-15 13:39 ` Cy Schubert - ITSD Open Systems Group
2001-05-15 15:31 ` Rik van Riel
2001-05-15 17:24 ` Matt Dillon
2001-05-15 23:55 ` Roger Larsson
2001-05-16 0:16 ` Matt Dillon
2001-05-16 8:23 ` Terry Lambert
2001-05-16 17:26 ` Matt Dillon
2001-05-08 20:52 ` Kirk McKusick
2001-05-09 0:18 ` Matt Dillon
2001-05-09 2:07 ` Peter Jeremy
2001-05-09 19:41 ` Matt Dillon
2001-05-12 14:28 ` Rik van Riel
2001-05-08 12:25 ` Scott F. Kaplan
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=3B04BA0D.8E0CAB90@mindspring.com \
--to=tlambert2@mindspring.com \
--cc=arch@FreeBSD.ORG \
--cc=crandall@matchlogic.com \
--cc=dillon@earth.backplane.com \
--cc=linux-mm@kvack.org \
--cc=riel@conectiva.com.br \
--cc=roger.larsson@norran.net \
--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