[lc-devel] spin_lock() evasion

[John R M. <jm...@st...>]

I'm still wrestling with instability.  I'm pondering trying to remove the 
need for so many spinlocks later (particularly, during compression and 
decompression) by marking algorithms' data as "in use" and attempting to 
allow multiple pages to be compressed/decompressed in parallel.  Here's a 
basic flow:

- Enter compress/decompress function
- Find algorithm entry
- Initialize a data for the algoritm
- compress/decompress the page or fragment
- free the data for the algorithm
- leave the compress/decompress function

This would further be aided by limiting how many data can be allocated at 
one time and queing all requests.  Another method would be to start 
queing requests when available RAM gets too low.

The problem here is that a series of interrupts may cause the retrieval 
of a page to be delayed, or may cause a series of calls to 
decompress/compress pages.  The code can be made to do it and the 
spin_lock()s can be inside an #ifndef though.  It'd be pretty simple to 
code (once the code is actually working the way it is), as would be 
dynamic data allocation.  However, with the static data allocation, 
you're guarenteed the memory needed to decompress/compress a page.

If someone could explain to me why a lot of stuff is where it is it'd be 
helpful :P



By the way, WK4x4 seems to run fine without the initialized data.  At 
least, it runs as fine as it can.  WKdm runs great, but it gets the WK 
data initialization.

--Bluefox Icy