A JFFS2 optimization related to syslog

A JFFS2 optimization related to syslog

[Ferenc Havasi]

Dear All,

If JFFS2 is used as root filesystem, syslogd/klogd can cause problems,
because every log line are written out individually, so the log file
will contain a lot of small nodes. Because a log file can be very large
(over 30M in our case) it can cause large memory consuption and can make
the system very slow, especially at opening it after next reboot
(becauseof the large frag-tree). Unforunatelly garbage collecting also
does not help, because none of the nodes is obsocalated.

The small patch below can help a lot. The idea behind it is very simple:
if there is a write request to write out the end of a page (4K) it will
write out the full page, not only the last part of it. The result of it
will be:
- small nodes will be obscolated
- garbage collector will be able to delete them
- after next reboot, when the file is under opening only this "large"
node will be read, the small node will not be parts of the frag tree
(thanks to Artem's improvement)

We think it can be usefull not only for us, and now we don't know about
any drawback.

May we commit it into CVS?

Regards,
Ferenc



diff -Narup Mtd-orig/fs/jffs2/file.c mtd/fs/jffs2/file.c
--- Mtd-orig/fs/jffs2/file.c    2005-11-07 12:14:39.000000000 +0100
+++ mtd/fs/jffs2/file.c    2006-04-11 16:35:15.000000000 +0200
@@ -221,6 +221,9 @@ static int jffs2_commit_write (struct fi
            page up to date, to prevent page_cache_read() from
            trying to re-lock it. */
         SetPageUptodate(pg);
+    } else if (end == PAGE_CACHE_SIZE) {
+        start = 0;
+        aligned_start = 0;
     }
 
     ri = jffs2_alloc_raw_inode();

Re: A JFFS2 optimization related to syslog

[Jörn Engel]

On Tue, 18 April 2006 13:09:49 +0200, Ferenc Havasi wrote:
> 
> If JFFS2 is used as root filesystem, syslogd/klogd can cause problems,
> because every log line are written out individually, so the log file
> will contain a lot of small nodes. Because a log file can be very large
> (over 30M in our case) it can cause large memory consuption and can make
> the system very slow, especially at opening it after next reboot
> (becauseof the large frag-tree). Unforunatelly garbage collecting also
> does not help, because none of the nodes is obsocalated.

obsoleted

> The small patch below can help a lot. The idea behind it is very simple:
> if there is a write request to write out the end of a page (4K) it will
> write out the full page, not only the last part of it. The result of it
> will be:
> - small nodes will be obscolated
> - garbage collector will be able to delete them
> - after next reboot, when the file is under opening only this "large"
> node will be read, the small node will not be parts of the frag tree
> (thanks to Artem's improvement)
> 
> We think it can be usefull not only for us, and now we don't know about
> any drawback.

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.

> May we commit it into CVS?

Fine with me.  CVS was recently declared dead, so you might want to
commit to git instead.  dwmw2 sent a mail about it to the list.

Jörn

-- 
Data expands to fill the space available for storage.
-- Parkinson's Law

Re: A JFFS2 optimization related to syslog

[Artem B. Bityutskiy]

Hello Ferenc,

Ferenc Havasi wrote:
> Dear All,
> 
> If JFFS2 is used as root filesystem, syslogd/klogd can cause problems,
> because every log line are written out individually, so the log file
> will contain a lot of small nodes. Because a log file can be very large
> (over 30M in our case) it can cause large memory consuption and can make
> the system very slow, especially at opening it after next reboot
> (becauseof the large frag-tree). Unforunatelly garbage collecting also
> does not help, because none of the nodes is obsocalated.
Hmm,

for this testcase you actually want to write entire page if this is the 
last page of this file. But your patch writes entire page if the current 
fragment ends at the end of page, which is different.

I mean, you probably want to do something like this instead:

if ((inode->i_size >> PAGE_CACHE_SHIFT) >= pg->index) {
     /*
      * This is the last page, so unconditionally re-write it fully.
      */
     start = 0;
}

-- 
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.

Re: A JFFS2 optimization related to syslog

[Artem B. Bityutskiy]

Artem B. Bityutskiy wrote:
> if ((inode->i_size >> PAGE_CACHE_SHIFT) >= pg->index) {
>     /*
>      * This is the last page, so unconditionally re-write it fully.
>      */
>     start = 0;
> }
> 
Oh, actually

if ((inode->i_size >> PAGE_CACHE_SHIFT) == pg->index)

-- 
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.

Re: A JFFS2 optimization related to syslog

[Jörn Engel]

On Tue, 18 April 2006 15:46:22 +0400, Artem B. Bityutskiy wrote:
> Ferenc Havasi wrote:
> >Dear All,
> >
> >If JFFS2 is used as root filesystem, syslogd/klogd can cause problems,
> >because every log line are written out individually, so the log file
> >will contain a lot of small nodes. Because a log file can be very large
> >(over 30M in our case) it can cause large memory consuption and can make
> >the system very slow, especially at opening it after next reboot
> >(becauseof the large frag-tree). Unforunatelly garbage collecting also
> >does not help, because none of the nodes is obsocalated.
> Hmm,
> 
> for this testcase you actually want to write entire page if this is the 
> last page of this file. But your patch writes entire page if the current 
> fragment ends at the end of page, which is different.
> 
> I mean, you probably want to do something like this instead:
> 
> if ((inode->i_size >> PAGE_CACHE_SHIFT) >= pg->index) {
>     /*
>      * This is the last page, so unconditionally re-write it fully.
>      */
>     start = 0;
> }

When appending single bytes to a file, this would be rather wasteful,
wouldn't it?  Ferenc's trick is to rewrite the full page only when
completing it, not all the time.

But it might make sense to only add the optimization for the end of a
file, which catches the syslog case and misses others where the
optimization would hurt more than it helps.

Jörn

-- 
You ain't got no problem, Jules. I'm on the motherfucker. Go back in
there, chill them niggers out and wait for the Wolf, who should be
coming directly.
-- Marsellus Wallace

Re: A JFFS2 optimization related to syslog

[David Woodhouse]

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

Re: A JFFS2 optimization related to syslog

[David Woodhouse]

On Wed, 2006-04-19 at 12:00 +0100, David Woodhouse wrote:
> 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.

Something like this, perhaps....?

http://git.infradead.org/?p=users/dwmw2/merge-2.6.git;a=commitdiff;h=51d838550c9aaf346e918d7964b2cb66ecd61b8d

-- 
dwmw2

Re: A JFFS2 optimization related to syslog

[Jörn Engel]

On Wed, 19 April 2006 13:45:38 +0100, David Woodhouse wrote:
> On Wed, 2006-04-19 at 12:00 +0100, David Woodhouse wrote:
> > 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.
> 
> Something like this, perhaps....?
> 
> http://git.infradead.org/?p=users/dwmw2/merge-2.6.git;a=commitdiff;h=51d838550c9aaf346e918d7964b2cb66ecd61b8d

Too complicated, imo.  The patch writes a pristine node, if
1) node is last node of page,
2) node is last node of file,
3) other nodes exist in the same eraseblock.

Condition 1 makes sense.  2 can be argued about.  Maybe a benchmark or
two can show whether it makes sense or not.  3 is fairly complicated
and I fail to see what it buys us.  If the other fragments are in
seperate eraseblocks, why shouldn't we write out a pristine node?

Jörn

-- 
Schrödinger's cat is <BLINK>not</BLINK> dead.
-- Illiad

Re: A JFFS2 optimization related to syslog

[David Woodhouse]

On Wed, 2006-04-19 at 14:55 +0200, Jörn Engel wrote:
> 
> Too complicated, imo.  The patch writes a pristine node, if
> 1) node is last node of page,
> 2) node is last node of file,
> 3) other nodes exist in the same eraseblock.
> 
> Condition 1 makes sense.  2 can be argued about.  Maybe a benchmark or
> two can show whether it makes sense or not.  3 is fairly complicated
> and I fail to see what it buys us.  If the other fragments are in
> seperate eraseblocks, why shouldn't we write out a pristine node?

Fair enough. I've committed a (cosmetic) variant of Ferenc's original
patch then.

-- 
dwmw2