Linux NILFS development
 help / color / mirror / Atom feed
From: "Gergely Gábor" <elentirmo.gilgalad-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
Subject: Re: some notes on a memory leak
Date: Sat, 16 Feb 2008 23:13:20 +0100	[thread overview]
Message-ID: <20080216231320.05db87a1@vosztok> (raw)
In-Reply-To: <20080215.150709.13051610.ryusuke-sG5X7nlA6pw@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 2195 bytes --]

Greetings!
> 
> I'd like to append a note.
> 
> NILFS has two different things about the cache usage than ordinary
> filesystems:
> 
> (1) Since the cleaner clowls over a partition, it adds new pages into a cache
>     of the block device one after another during it operates on the background.
> 
> (2) Some blocks, for example the blocks to store header information of each
>     segment, are allocated incrementally into the cache of the block device. 
>     So, bursty writes or frequent sync writes may bloat it.
>     Conversely, the turnover of buffers for files or meta data should not be 
>     higher than usual fs because a same buffer serves for a same file offset
>     even when its physical disk address changes.
> 
generally nilfs2 performs well. rtorrent triggers some error.

> I made a patch to minimize the bloat of bdev cache due to the second
> difference.
> If you are bothered with that, please test the following patch.
> From my local tests, it didn't make no remarkable difference.
I tried the patch, i see no basic difference. the fs generally works fine, but rtorrent can make it consume all memory, and not free it after exit. just as if the cache entries didn't age (well i don't know how to describe the situation better with my naive words). I have tried setting the following, with no luck:
 vm.vfs_cache_pressure = 200
and even 
 vm.drop_caches = 3 

according to docs, it should have had some effect, but neither had any (in case of rtorrent's garbage)

the "pages" cached by rtorrent can't be flushed out of cache even when rtorrent has quit. This may as well be he fault of rtorrent, but I can remember an ext3 bug that was found by an rtorrent malfunction, and still, it is not right. (other programs generally seem to release cache after some time after having been closed). If i start a hash check on a near complete dvd image in rtorrent (0.7.9 version) i can waste my ram in less than 2 minutes!

umount helps. but now i can do my works on my notebook aswell.

Best Regards:
-- 
Gergely Gábor <elentirmo.gilgalad-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

* random fortune:
Above all things, reverence yourself.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users

      parent reply	other threads:[~2008-02-16 22:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-14  0:02 some notes on a memory leak Gergely Gábor
2008-02-15  3:18 ` Ryusuke Konishi
2008-02-15  6:07 ` Ryusuke Konishi
     [not found]   ` <20080215.150709.13051610.ryusuke-sG5X7nlA6pw@public.gmane.org>
2008-02-15  6:42     ` Ryusuke Konishi
2008-02-16 22:13     ` Gergely Gábor [this message]

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=20080216231320.05db87a1@vosztok \
    --to=elentirmo.gilgalad-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.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