This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: JFFS2 eats memory


On Mon, 2004-07-12 at 16:42 +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.

That would be a single struct jffs2_raw_node_ref. That's 16 bytes and I
assume the other 8 is allocator overhead -- unless you're on a 64-bit
platform where it is actually 24 bytes.

It wouldn't be hard to cut the jffs2_raw_node_ref down to 12 bytes
instead of 16, btw. There are _many_ of these. See the discussion about
making the commented ref_totlen() macro in nodelist.h actually work in
100% of cases, rather than only 95% as it would at the moment, and then
we could drop the totlen field.

> Presumably when the raw nodes in the file fragement list are marked as
> obsolete, they are no longer required, but are not freed.

The jffs2_raw_node_ref structures _are_ required. You need those in
order to be able to find all the parts of a given inode if/when it gets
opened again.

But the file fragment list, which is held in memory for as long as the
eCos-specific "struct _inode" exists, is not necessarily required.

You've made the eCos code prune its inode cache more aggressively. Be
careful that you don't pessimise the garbage-collection code. It will
often spend a fair bit of time opening an inode (with
jffs2_gc_fetch_inode()), doing some garbage collection, and then
releasing it again (with jffs2_gc_release_inode()).

Now that we have those methods, actually, you could mark only _those_
inodes so that they remain in cache for a little while longer, while
instantly releasing inodes from your icache if they were opened by the
user.

> Q: Is this fundamentally impossible or a "bad idea" to fix?

Not at all. Everything under fs/ecos/ is yours to do with as you see
fit. I'm happy to advise but I'd _really_ like to see someone rewrite
the eCos parts altogether; they still look _far_ too much like a
hacked-up Linux compatibility layer, and they no longer need to.

-- 
dwmw2


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]