[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JFFS2 is broken
> Well there are two things there.
> 1. You could wake the GC and sleep on it using sleep/wakeup or
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
I'll poke at this on Monday.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to email@example.com