All of lore.kernel.org
 help / color / mirror / Atom feed
From: kanoj@google.engr.sgi.com (Kanoj Sarcar)
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Mark Hahn <hahn@coffee.psychology.mcmaster.ca>, linux-mm@kvack.org
Subject: Re: how text page of executable are shared ?
Date: Tue, 28 Mar 2000 17:59:45 -0800 (PST)	[thread overview]
Message-ID: <200003290159.RAA95992@google.engr.sgi.com> (raw)
In-Reply-To: <20000329020103.I17288@redhat.com> from "Stephen C. Tweedie" at Mar 29, 2000 02:01:03 AM

> 
> Hi,
> 
> On Tue, Mar 28, 2000 at 10:58:00AM -0500, Mark Hahn wrote:
> > 
> > could you comment on a problem I'm seeing in the current (pre3) VM?
> > the situation is a 256M machine, otherwise idle (random daemons, no X,
> > couple ssh's) and a process that sequentially traverses 12 40M files
> > by mmaping them (and munmapping them, in order, one at a time.)
> > 
> > the observation is that all goes well until the ~6th file, when we 
> > run out of unused ram.  then we start _swapping_!  the point is that 
> > shrink_mmap should really be scavenging those now unmapped files,
> > shouldn't it?
> 
> Well, you've filled the whole of memory with recently referenced page 
> cache pages.  The page cache scanner can now scan the whole of physical
> memory without finding anything which is "old" enough to be evicted. 
> It is only natural that it will start swapping at that point!
> 
> The swapping should be brief if all is working properly, though, as the
> shrink_mmap() will rapidly find itself on the second pass over memory
> and will start finding things which have been aged on the first pass 
> and not used since.
> 
> --Stephen
> --
> 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/
> 

As I mentioned to Mark in private mail, it might be worthwhile looking
into the possiblity of using MADV_DONTNEED to discard file pages from 
the cache. In some os'es, I think msync(MS_INVALIDATE) actually takes
the page out from the cache.

Kanoj
--
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/

  reply	other threads:[~2000-03-29  1:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-28  3:51 how text page of executable are shared ? pnilesh
2000-03-28 13:22 ` Stephen C. Tweedie
2000-03-28 15:58   ` Mark Hahn
2000-03-28 18:10     ` Andrea Arcangeli
2000-03-29  1:01     ` Stephen C. Tweedie
2000-03-29  1:59       ` Kanoj Sarcar [this message]
2000-03-29  5:21       ` Andrew Morton
2000-03-29 13:45         ` Stephen C. Tweedie
  -- strict thread matches above, loose matches on Subject: below --
2000-03-29  7:46 pnilesh
2000-03-29 13:49 ` Stephen C. Tweedie

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=200003290159.RAA95992@google.engr.sgi.com \
    --to=kanoj@google.engr.sgi.com \
    --cc=hahn@coffee.psychology.mcmaster.ca \
    --cc=linux-mm@kvack.org \
    --cc=sct@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.