JFFS2 is broken

[David Woodhouse]

alan at lxorguk.ukuu.org.uk said:
> Well there are two things there.
> 1.	You could wake the GC and sleep on it  using sleep/wakeup or
> 	semaphores

I've tried to keep the GC thread optional. That's not set in stone - but we 
ought to be able to fix this - there's no real reason why the GC in the 
write() path should behave like this.

Thinks... is the BKL still held in write()? Should we be releasing it?

> 2.	Profile the kernel and find out where it is tight looping. I can't
> 	see any reason for tight loops except for the compression itself
> 	so it suggests a code bug.

AFAIR the compression routines aren't turning up on the profiles. But then 
we're getting 71 timer ticks in a 30-second period, according to the 
profiles I saw.

> Finally within the compression loops you can check current->
> need_resched and if it is set call schedule() to allow the compression
> to switch to other tasks at the point it has used its time slice. 

We already do this between each node we move, in the garbage collection
loop. Doing it inside the compression loops would be possible - although
it'd confuse mkfs.jffs2, which just imports those files directly too.

Better still to avoid decompressing and recompressing data when we move 
nodes intact.

I'll poke at this on Monday. 

--
dwmw2