On Thursday 26 April 2007 08:52, Vitaly Wool wrote:
> On 4/25/07, Charles Manning <manningc2@actrix.gen.nz> wrote:
> > There are some ideas I have for playing with these numbers to get more
> > passive gcs to happen (thereby spreading the gc load). For example, it
> > would be interesting to dynamically increase the threshold.
>
> I wonder if it makes sense to trigger some async GC, for instance,
> after a read operation.
Well there's actually no reason why a seperate thread could not do gc in the
background too. All this requires is a thread that locks yaffs and calls the
gc function. I know that some non-Linux folk have done this to great effect.
It is particularly useful for pda/phone devices where the system can be
apparently idle (to the user) and doing some gc then will result in a more
responsive system when file system effort is done.
Major issue with gc in yaffs2 mode is that the shrink header mechanism
prevents optimum gc choices and prevents effective "passive gc". This often
forces the system to defer gc until "aggressive gc" kicks in, at which point
a lot of work is required. This can cause the gc effort to grind quite hard.
There are quite a few things that can be done to improve gc, but that's
currently at a lower priority to me than some other things I am working on.
These improvements include:
* Improvements to the way "passive gc" is done to get better spreading of gc
load. For example, partial gc of blocks, where we just copy a few pages at a
time, would significantly reduce "stall".
* Improvements in the way shrink headers are managed. The current approach
caters to the worst case only and as a result some efficiency is lost. Some
optimisations are possible to make the typical cases run far better, while
still being able to deal with the worst cases.
-- CHarles
(text/plain)