Re: [ECOS] FLASH API v.2 and interrupts

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Paul" == Paul D DeRocco <pderocco@ix.netcom.com> writes:

    >> From: Bart Veer
    >> 
    >> On other hardware the flash driver has to disable the cache
    >> before it can talk directly to the flash chip. You do not want
    >> interrupts or context switches while the cache is disabled, the
    >> resulting system performance would be terrible. The
    >> LEAVE_INTERRUPTS_ENABLED option is not available on hardware
    >> like this.

    Paul> That seems an odd assumption to make. In lots of systems,
    Paul> max CPU horsepower is only needed intermittently, and
    Paul> keeping the system responsive, say, to slow user input would
    Paul> be preferable to shutting everything down during flash
    Paul> writes.

Running with the cache disabled is likely to mean a performance
penalty of between one and two orders of magnitude. Now, if the system
is basically idle at the time of the flash operation then you might
get away with running for a while with the cache disabled. This would
require that the interrupt be fully serviced (ISR, possibly DSR,
possibly some thread-level work) before the next interrupt. The cpu
gets to context switch back to the thread performing the flash
operation, and progress would be made.

However, if the system is at all busy then chances are it won't manage
to service the interrupt before the next one comes in. If this happens
control may not return to the right thread for a long time, if ever,
so the flash operation does not complete in a reasonable time and the
cache remains disabled. To make matters worse, debugging this kind of
problem is going to be tricky.

In my opinion you would need an awful lot of confidence in your
predictions of the expected I/O loads and in your performance
profiling data to take the risk of running for an extended period of
time with no cache. Or else you would need a cpu which is spec'd
significantly higher than what the application really needs, adding to
the product costs.

A further complication is that the cache state is a simple toggle, not
a stack. Hence you could have code running after the interrupts which
disables the cache (even though it was still disabled by the flash
operation), then reenables it later. If/when the flash thread gets to
run again the driver will find the cache unexpectedly enabled, and
at that point you can expect things to go badly wrong.

So I believe it is sensible for the AMD V2 driver to disallow
LEAVE_INTERRUPTS_ENABLED on hardware where there are cache issues. The
alternative is just too dangerous. If people are really unhappy about
it then they have the source and can change it for their needs.

Bart
    
-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
       >>>> Visit us at ESC-UK  http://www.embedded.co.uk <<<<
       >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<<

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss