Strange automatic GC threshold ?
mw_phil at yahoo.co.uk
Mon Mar 19 15:04:56 EDT 2007
Josh Boyer <jwboyer <at> linux.vnet.ibm.com> writes:
> On Mon, 2007-03-19 at 19:17 +0100, Joakim Tjernlund wrote:
> > > I'd be interested to see how the behavior of GC differs with the
> > > proposed change. Theoretically, it seems to make sense to allow GC to
> > > make progress and it could help the "oh crap we're out of space" grind
> > > that seems to occur. My biggest concern would be if it actually made GC
> > > harder to do in the long run as the obsolete nodes could potentially get
> > > more scattered among the eraseblocks.
> > Can't be worse than current behavior as now the system becomes painfully
> > slow long before it starts GC. Perhaps one need one threshold to start
> > GC due to dirtiness and another one when to stop?
> Well, it can though. If the obsolete nodes are scattered throughout the
> blocks and moving them doesn't actually make any single eraseblock
> totally obsolete then you've eliminated the effectiveness of GC
> completely. That problem exists today of course, but I'm concerned it
> could happen with more frequency if we're GCing sooner. Maybe I'm just
> The often suggested idea of GCing into a completely separate block than
> the one you're writing into normally might help here. But I'm not sure
> how feasible that is at this moment.
Unfortunately, subjects like GC are notoriously easy to "improve" - only
to discover that the "improvement" either doesn't help, or makes things worse
or very bad in some situations.
For this, some kind of algorithm test by simulation would be a good idea.
In this way, many different scenarios can be "left to run" over many different
cases to compare performances and any delinquent behaviour.
More information about the linux-mtd