Re: [ECOS] JFFS2 eats memory

["Øyvind Harboe" <oyvind.harboe@zylin.com>]

On Tue, 2004-07-13 at 09:40, Andrew Lunn wrote:
> On Mon, Jul 12, 2004 at 04:42:11PM +0200, ?yvind Harboe wrote:
> > This issue has been discussed before, and although I have a workaround,
> > I'd dearly like to have it put to bed since it is starting to cause
> > problems elsewhere in my application:
> > 
> > - My code opens a file for writing with O_TRUNC set, performs
> > a single write call, closes the file.
> > - After closing the file, JFFS2 has eaten memory.
> > - With the attached modifcations to JFFS2, it "only" eats 24 bytes.
> > - If I unmount and remount JFFS2, no memory is "lost" and JFFS2 works
> > fine.
> > 
> > Presumably when the raw nodes in the file fragement list are marked as
> > obsolete, they are no longer required, but are not freed.
> > 
> > Q: Is this fundamentally impossible or a "bad idea" to fix?
> 
> How much memory are we talking about here in this example?

24 bytes* number of write() operations for each time a file is
truncated.

Additionally, memory is lost for other operations(e.g. deleting files),
but I don't have any numbers(24 bytes for every time a file is
deleted?).

I'd really like to see that JFFS2 memory usage was constant if the
number of files(and sections within those files) is constant. That way I
could just run my system and measure the maximum usage.

> The cache is there for a reason, so i would not want to
> unconditionally disable it. At least you need some CDL to control
> between fat & fast and slow & slim.

Is JFFS2 faster because it caches raw_node_ref's to deleted nodes?

Sounds strange.

The mount code simply ignores these nodes, which insinuates that caching
these nodes does not help performance.

> I would also suggest you consider extending the
> CYGNUM_FS_JFFS2_RAW_NODE_REF_CACHE_POOL_SIZE concept to the inode
> cache.  You can then control the size of the cache. 

AFAICT, this setting is no help in this case, because all it would do is
to cause JFFS2 operations to fail when running out of pool space instead
of when running out of overall system memory.

Further it would lock a piece of the overall system memory to JFFS2,
making the global memory situation worse.

> 
>         Andrew
-- 
Øyvind Harboe
http://www.zylin.com



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss