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

RE: Caching writes



Hi,

To resolve your blocking time, replace your usleep by a function that does
something like this:
void cfi_udelay( unsigned long us )
{
	if (current->need_resched)
		schedule();
	else
		udelay(us);
}
But do this only if your cache deamon can afford to be scheduled when
usleeping.
Also, look at the code of the driver you use to access the chip.  It may be
consuming a lot up cpu just doing spinlocks or tights while loops just
pooling data.  

	Although I am not an expert yet, I sense that you will have huge
problems with JFFS2 using caching writes to the flash, especially if the
cache occurs between the chip driver and the flash, because JFFS2 do write
check validation and erase check validation every time it performs such
operations.  If you cache what JFFS2 is trying to write or erase, it may
cause problems.  I think, although I am not sure, that JFFS2 does its own
caching, too.  So my bet on using another cache is to be very careful.
You'd be better to try doing tweaks on your chip driver, that would
certainly improve performance.


Frédéric Giasson





-----Original Message-----
From: William Jhun [mailto:wjhun@xxxxxxx.com]
Sent: Monday, July 23, 2001 11:25 PM
To: jffs-dev@xxxxxxx.com
Subject: Caching writes


Hello,

We are having issues with very long write cycles on our flash device and a
lack of a DMA controller. 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. (we're
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.

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?

Any thoughts appreciated,
William



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

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