Stopping the GC thread?

Hi there,

in "JFFS - A pratical guide" (http://www.embeddedlinuxworks.com/articles/jffs_guide.html) I read

"For completeness, I should mention that you can suspend and re-start the GC thread on demand by sending it a signal. A SIGSTOP and a SIGCONT can do that respectively."

I would like to be able to stop the garbage collection thread from within my application when doing some time critical things. Is it safe to just do a

~ # kill -s SIGSTOP pidof jffs2_gcd_mtd0

even if my root fs is on this JFFS2 partition?

(I just tried it now and it seems to work. But IIRC a while ago my system hung when I did something like that...)

Thanks,

Steven

Yes.

It shouldn't. The GC thread remains strictly an optimisation (and doesn't exist in the eCos port, etc.)

dwmw2

Thanks for that!
(How) Could I trigger the GC thread to test its impact on my application or the overall system performance? Is there a signal I could sent to start a GC?

Steven

mfg Steven Scholz

imc Meßsysteme GmbH
Voltastr. 5
13355 Berlin
Germany
fon: +49 30 467090-0
fax: +49 30 4631576

No. You used to be able to trigger it by repeatedly sending it SIGHUP but that doesn't work any more. I keep intending to make the thresholds tunable in /proc though, which you could abuse to do what you want.

dwmw2

So for now I just could hardcode the thresholds (ehm which BTW?) to some low value, recompile and test?

Steven

Hacking the thread_should_wake() function to _always_ return 1 ought to suffice.

Don't leave it running for ever on a flash chip you actually want to continue working though :)

dwmw2

David,

two more questions please.

1.) What happens if I send multiple SIGSTOPs or SIGCONTs to the thread? Does she handle (i.e. ignore) that properly?

2.) What happnens when I send a SIGSTOP in the middle of a running GC?
Will it stop immediately? Or will it take a while?
I suppose that a few more sectors will be examened and written... (10ms, 100ms, 1000ms ...???) Will it then just continue after a SIGCONT? Or will start all over again?

Thanks!

Steven

Should do.

It'll finish copying the node it's _currently_ garbage-collecting, which may involve decompressing up to a page of data, recompressing it and writing it out elsewhere. It may also need to wait for erases to complete.

Even after it's stopped, if there are erasable blocks on the queue, they'll continue to be erased in the background by kupdated. You cannot prevent that.

'sector'? Read http://sources.redhat.com/jffs2/jffs2.pdf

It'll just continue.

dwmw2

David,

But the impact on system performance done by kupdated is not as critical as the one that's done by the GC intself, is it?

I meant flash sectors.

Steven

Assuming your flash supports erase-suspend, no. Certainly it doesn't eat lots of CPU time like GC can.

Whole erase blocks? God no, we GC one data (or dirent or whatever) node at a time, which is never going to be larger than about 4KiB.

dwmw2

The impact on system performance is practically zero, really. The work that GC is doing has to be done anyway. The only question is, when will this work be done.

Try the following:
time for i in seq 10; do

	cp $largefile $jffs2;
	sleep 3;
	rm $jffs2/$largefile;
	sleep 3;

done

$largefile should be around 50% or of fs size, roughly.

Run this with and whithout the sleeps. Notice that the difference it not just one minute of idle time, it is more in the order of 2, ignoring the idle time. And I bet you a fiver that you get the same order between enabled and disabled GC if you keep the sleep.

GC eats up cpu cycles when the system is idle, so you have more left when you are under pressure. And that is a Good Thing(tm).

Most people prefer to call them erase blocks or something similar. :)

Jörn

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein