[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: impacts during GC
> You need to be prepared to take potentially large latencies during a
> GC run though, for example during erase of a sector. Depending on the
> flash type it can take up to 2 seconds I think. During that time you
> can neither read nor write. Some more modern flashes can do that but I
> don't know if the MTD layer knows about it, or if the GC thread in
> JFFS does..
It's mostly implemented. The CFI chip drivers know how to interrupt erases and
resume them. But I had SMP problems with JFFS, so I added a single semaphore
around all operations, which effectively prevents it from requesting
concurrent flash access from the low-level drivers.
That can be fixed when someone has enough time (and enough caffeine) to go
through the locking and make it more fine-grained.
Note that in 2.2/2.4, you can send the GC thread a SIGSTOP when you want it
to stop, and you'll then only do just-in-time garbage collection to make
space for writes which are just about to happen. Send it a SIGCONT to let
it start up again.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org