public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
Cc: linux-mtd@lists.infradead.org
Subject: Re: A JFFS2 optimization related to syslog
Date: Wed, 19 Apr 2006 12:00:26 +0100	[thread overview]
Message-ID: <1145444426.13200.71.camel@pmac.infradead.org> (raw)
In-Reply-To: <20060418113258.GA4720@wohnheim.fh-wedel.de>

On Tue, 2006-04-18 at 13:32 +0200, Jörn Engel wrote:
> Very interesting idea.  I had another one which is more complicated
> and it looks like yours is much better.  Just for completeness, here
> is mine:
> o For every node with less than one page uncompressed size, account it
>   some dirty space for it.
> o Node header is 68 bytes (on 32bit).  Therefore, a node with 1/2 page
>   uncompressed size should cause 34 bytes of "dirty space".
> o Complete formula:
>   dirty_space = 68 * (PAGE_SIZE - ri->csize) / PAGE_SIZE
> o Possibly don't account dirty space if node is last node of a file.
> 
> With this little hack, tiny nodes would be garbage collected for being
> "dirty space".
> 
> Maybe both approaches would make sense, but yours is much simpler and
> should be used independently of whether mine makes sense.

My idea was similar to Jörn's but slightly simpler in the
implementation. We already make a distinction between REF_PRISTINE and
REF_NORMAL nodes, and I thought that we should keep track of those
counts in jeb->pristine_size and jeb->normal_size instead of the
existing jeb->used_size which holds them both. Then we should use that
information when selecting blocks to be garbage collected -- we should
tend to pick blocks with REF_NORMAL nodes for garbage collection.

This would fix the problem which Ferenc refers to, that none of the
nodes are obsoleted. However, it still only means that the nodes would
be garbage-collected in the fullness of time -- it's not clear how
_much_ of an effect that would have -- you could still end up with whole
eraseblocks full of these REF_NORMAL nodes, if there's plenty of free
space and garbage collection isn't being pressured.

So even if we do that, I think Ferenc's patch _also_ makes sense,
because it fixes the worst of the problem at its source. We could
perhaps make it conditional -- only write out the whole page if there's
more than N nodes already in the same page, or if the previous nodes for
the same page are in the same eraseblock _and_ the new 'full' node would
actually fit in the eraseblock.

-- 
dwmw2

  reply	other threads:[~2006-04-19 11:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-18 11:09 A JFFS2 optimization related to syslog Ferenc Havasi
2006-04-18 11:32 ` Jörn Engel
2006-04-19 11:00   ` David Woodhouse [this message]
2006-04-19 12:45     ` David Woodhouse
2006-04-19 12:55       ` Jörn Engel
2006-05-14  3:22         ` David Woodhouse
2006-04-18 11:46 ` Artem B. Bityutskiy
2006-04-18 11:51   ` Artem B. Bityutskiy
2006-04-18 12:05   ` Jörn Engel

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=1145444426.13200.71.camel@pmac.infradead.org \
    --to=dwmw2@infradead.org \
    --cc=joern@wohnheim.fh-wedel.de \
    --cc=linux-mtd@lists.infradead.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