Re: excessive swap-in time
- From: talon@xxxxxxxxxxxxxxxx (Michel Talon)
- Date: Mon, 17 Mar 2008 22:01:41 +0000 (UTC)
phil-news-nospam@xxxxxxxx wrote:
in (within a percentage of real RAM limit that can be tuned). Then these
"most active working processes" would be marked and their pages are not
to be chosen for eviction unless all other processes are gone (in which
case, it must be time to recalculate working sets or adjust the active
process list, anyway). The idea is, the most recently made active process
should not be an eviction target. When a process changes to active state,
then things need to be recalculated (which processes are active ones is
certainly not a static condition).
Note that a given page may be shared by several processes, see e.g.
shared libraries, or several instances of the same text executable.
But a given executable may have pages which have not been accessed
since ages and will not probably be soon, think e.g. to images
cached by firefox in a page you have already seen. So it may be that the
only relevant statistics is the usage of each page without consideration
to the process which use them. By the way, new processes are scheduled
between 100 and 1000 times a second, which is probably faster than
retreiving things from swap (think latency of the disk) another
reason why considering activity on processes may not be a good idea.
--
Michel TALON
.
- References:
- excessive swap-in time
- From: phil-news-nospam
- Re: excessive swap-in time
- From: Jan Knutar
- Re: excessive swap-in time
- From: phil-news-nospam
- Re: excessive swap-in time
- From: David Schwartz
- Re: excessive swap-in time
- From: phil-news-nospam
- Re: excessive swap-in time
- From: Michel Talon
- Re: excessive swap-in time
- From: Rainer Weikusat
- Re: excessive swap-in time
- From: Michel Talon
- Re: excessive swap-in time
- From: phil-news-nospam
- excessive swap-in time
- Prev by Date: Re: Dynamic linking with LD_PRELOAD - get it compiled
- Next by Date: Re: excessive swap-in time
- Previous by thread: Re: excessive swap-in time
- Next by thread: Re: excessive swap-in time
- Index(es):