[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Slow jffs2 startup on DOM



Great

Any idea why kupdate consumes so much CPU? Erasing blocks should
use very little CPU. If kupdate behaved better it would not matter that
much WHEN blocks are erased. Kupdate(I think) compleatly blocks my apps
for many seconds when it kicks in after reboot and finds a lot of blocks to
erase.

Maybe it's kupdate that is responsible for long blocking times when
the FS starts to get full as well?

      Jocke
PS.
   Any chance to see this patch in the jffs2-2_4-branch too?

>
> (moved to correct list)
>
> Joakim.Tjernlund@xxxxxxx.se said:
> > I see this too. Every time I boot with a fresh JFFS2 image or if I
> > remove som big files and reboot(does not matter if I wait before I
> > reboot), kupdate runs like hell, consuming almost all cpu for a while
> > before it calms down. If I monitor the output from 'df', I see that
> > the Use field slowly rises to 100% and then its drops back to my real
> > usage of the JFFS2 partition.
>
> That one I can explain, although it shouldn't make any difference whether
> you reboot cleanly or not.
>
> When we obsoleted the final node in an eraseblock, we used to stick it
> straight on the erase_pending_list for recycling. That screwed the wear
> levelling - if you continually create and remove {lots of,large} files,
> then you'll keep using the same blocks over and over again.
>
> So I took that out, and we just file those blocks on the dirty_list for
> later erasure by the garbage-collection code. However, the mount code will
> observe that they're entirely empty and file them for immediate erasure,
> and this is what makes kupdated eat your CPU on remount.
>
> I see two options for fixing this.
>
> First, we could partially revert the earlier change - mostly just erase
> the block straight away as we used to, but _occasionally_ put it on the
> dirty_list to keep the wear levelling moving.
>
> Secondly, we could prevent the code from erasing the all-dirty blocks
> immediately on mount, by filing them at the front of the dirty_list so
> they're first up for garbage-collection.
>
> I've just committed the first option to CVS, which should render the
second
> pointless - there will rarely be many such blocks anyway.
>
> Thomas - this may break the NAND support, as it takes some NAND-specific
> code out of #if 0. Although the NAND support was already broken, because
> that code really should have been used :)
>
> In the 1 in 64 times that we just stick this block on the dirty_list
instead
> of erasing it immediately (or putting it on the erase_pending_wbuf list),
> what stops the GC code from subsequently erasing it before the wbuf is
> flushed? (Until today, that was 64 in 64 times.)



To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com