[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Caching writes
This is from Vipin, I screwed up a non-member bounce (vipin please check
your subscription address)
To: William Jhun <firstname.lastname@example.org
From: Vipin Malik <email@example.com>
Subject: Re: Caching writes
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 08:24 PM 7/23/2001 -0700, William Jhun wrote:
>We are having issues with very long write cycles on our flash device and a
>lack of a DMA controller.
I don't think that *any* system out there uses a DMA controller to do
writes from RAM to flash.
Your slow write speeds must be coming from not being (or not having) write
bypass mode when writing to the flash.
A DMA controller will not solve that anyway.
At 60seconds/MiB your flash writes speeds are ~17KB/sec!
And you indicate that your chip has a cache- so it must be a "reasonable"
processor in terms of performance (i.e. 8051's don't have caches!)
(i.e. the delay is (should) not be in the processor itself).
Something doesn't compute. Are you sure where your delays are? Can you list
some more details: Processor, bus width of the flash, type of flash etc.
If I was a betting man, I would speculate that you are experiencing some of
the dreaded long "jitter latencies" that I tested and encountered (and
detailed on this thread not that long ago). See archives or my web site for
Most of the time is spend in garbage collection. When you are copying the
file, do a "top" and see if the garbage collecting thread is running full
>Copying a half megabyte file onto a jffs2
>filesystem takes 30-40 seconds with very high CPU utilization.
>Given our situation, we are not able to change the hardware configuration
>much to accomodate for these long writes (e.g., by adding a DMA
>controller, etc). As a result, I have begun writing a write-back cache
>implementation in software that will slowly (via a low priority kernel
>daemon) trickle data out to the flash device while retaining full cache
>coherency. This will allow reasonable response times and an upper-bound to
>CPU utilization (which can be changed dynamically) It can be hooked onto
>either jffs2 or the mtd device itself.
>However, a few questions:
>1) Is there a more obvious way to deal with this problem? We have some
>other timing-critical software running on the same CPU, so there must be a
>cap to the amount of CPU utilization caused by writing to flash.
Are you running Linux? What you say sounds like what one may have to do in
a cooperative multitasking system.
Why can't you run your "time critical" task is a POSIX real time task and
do all file system IO via a separate daemon that runs as a normal Linux
task. Now, even if the file system IO task gets blocked (due to the above
mentioned latency issue), your critical task can continue running when it
Just for reference, on a 133MHz AMD SC520 (a DX4 486 w/ 16KB cache), my
worst case jitter for a periodic POSIX task was ~54ms even with the
underlying JFFS2 flash fs completely blocked due to garbage collection.
>doing a lot of usleep()s to insure the neccessary timing constraints for
>the flash device). Additionally, write()s cannot block for long; we would
>like to have a fairly reasonable response time for calls to the filesystem
>with the trade-off being low-volume (however possibly bursty) traffic.
HeHe, what you needs is the following:
>2) My write-back cache implementation does not insure ordering of writes
>from jffs. Though it should not be excessive, there will be a case where
>one write from jffs will complete before a previously-issued write. I'm
>working on a way to correct this. Given a power failure, how severe could
>this get, even if only a few write()s are out-of-order?
HeHe, what you needs is the following:
Why is your flash cached? That's a very difficult situation and one that
AFAIK is not solved yet.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org