All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ashley <dash@xdr.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Cached memory never gets released
Date: Tue, 29 Jun 2004 09:18:26 -0700	[thread overview]
Message-ID: <200406291618.i5TGIQ8F028141@xdr.com> (raw)

Ross Biro wrote:
>First it's absolutely normal for cache to fill up all available
>memory.  What's not normal is to not free unused cache when memory is
>needed.
>My best guess is that this isn't a kernel problem, but a bug in flash
>and all that memory really is used.  The next step I would do is go


In the thread this is made clear somewhat, but when I post new
emails I don't summarize all that is known about the problem.

I can kill all user processes, including mozilla,
XFree86, and everything else except an sshd to
log into the system, and the cache is still not
released.

The cached memory is just *gone*, no recovery, bye-bye, history.

I am experimenting with strace to see what mozilla is
doing. It does repeatedly
Open file X with O_EXCL and result is -1 EEXIST
Open file Y with O_EXCL and it is created
Close that file
Open file Y without O_EXCL
Allocate some memory
write to Y
close file Y
later unlink file Y

I tried duplicating this sequence of events thinking it
could be something related to the
create/write/close/delete sequence of a file,
perhaps the file's inode isn't getting freed. However my
test program didn't cause the same trouble.

Specifically the discussed strace output includes this:
mkdir("/root/mynfsarea/mozilla/plugtmp", 0777) = -1 EEXIST (File exists)
open("/root/mynfsarea/mozilla/plugtmp/ipg_template.swf", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL|0x8000, 0600) = -1 EEXIST (File exists)
open("/root/mynfsarea/mozilla/plugtmp/ipg_template-1.swf", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL|0x8000, 0600) = 30
close(30)                               = 0
open("/root/mynfsarea/mozilla/plugtmp/ipg_template-1.swf", O_WRONLY|O_CREAT|O_TRUNC|0x8000, 0600) = 30
brk(0x82d8000)                          = 0x82d8000
gettimeofday({1088521806, 310960}, NULL) = 0
brk(0x82d9000)                          = 0x82d9000
brk(0x82db000)                          = 0x82db000
brk(0x82dc000)                          = 0x82dc000
brk(0x82dd000)                          = 0x82dd000
brk(0x82de000)                          = 0x82de000
brk(0x82df000)                          = 0x82df000
brk(0x82e0000)                          = 0x82e0000
brk(0x82e1000)                          = 0x82e1000
brk(0x82e2000)                          = 0x82e2000
write(30, "FWS\6o\211\0\0x\0\7\320\0\0\27p\0\0\36\n\0C\2\377\377\377"..., 35183) = 35183
brk(0x82ea000)                          = 0x82ea000
close(30)                               = 0
... very much later in log
unlink("/root/mynfsarea/mozilla/plugtmp/ipg_template-1.swf") = 0


My thinking here is that every reload of the page steals about 200K
of cache memory that can never be recovered, and that
the total size of these files in the plugtmp directory (mozilla's
cache) is on the order of 200k.

-Dave

             reply	other threads:[~2004-06-29 16:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-29 16:18 David Ashley [this message]
2004-06-30  1:25 ` Cached memory never gets released Ross Biro
  -- strict thread matches above, loose matches on Subject: below --
2004-06-29 15:07 David Ashley
2004-06-29 16:00 ` Ross Biro
2004-06-27  3:24 David Ashley
2004-06-24 17:14 David Ashley
2004-06-24 14:48 David Ashley
2004-06-24 15:49 ` Ross Biro
2004-06-23 18:35 David Ashley
2004-06-23 18:44 ` Doug McNaught
2004-06-23 15:31 David Ashley

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=200406291618.i5TGIQ8F028141@xdr.com \
    --to=dash@xdr.com \
    --cc=linux-kernel@vger.kernel.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 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.