Stopping the GC thread?

Stopping the GC thread?

[Steven Scholz]

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

Re: Stopping the GC thread?

[David Woodhouse]

On Wed, 2003-06-11 at 17:03, Steven Scholz wrote:
> Is it safe to just do a
> 
> ~ # kill -s SIGSTOP `pidof jffs2_gcd_mtd0`
> 
> even if my root fs is on this JFFS2 partition?

Yes.

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

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

-- 
dwmw2

Re: Stopping the GC thread?

[Steven Scholz]

David Woodhouse schrieb:
> On Wed, 2003-06-11 at 17:03, Steven Scholz wrote:
> 
>>Is it safe to just do a
>>
>>~ # kill -s SIGSTOP `pidof jffs2_gcd_mtd0`
>>
>>even if my root fs is on this JFFS2 partition?
> 
> 
> Yes.
> 
> 
>>(I just tried it now and it seems to work. But IIRC a while ago my 
>>system hung when I did something like that...)
> 
> 
> It shouldn't. The GC thread remains strictly an optimisation (and
> doesn't exist in the eCos port, etc.)
> 

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

Re: Stopping the GC thread?

[David Woodhouse]

On Wed, 2003-06-11 at 17:12, Steven Scholz wrote:
> (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?

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

Re: Stopping the GC thread?

[Steven Scholz]

David Woodhouse schrieb:
> On Wed, 2003-06-11 at 17:12, Steven Scholz wrote:
> 
>>(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?
> 
> 
> 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.
> 

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

Steven

Re: Stopping the GC thread?

[David Woodhouse]

On Wed, 2003-06-11 at 17:20, Steven Scholz wrote:
> So for now I just could hardcode the thresholds (ehm which BTW?) to 
> some low value, recompile and test?

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

Re: Stopping the GC thread?

[Steven Scholz]

David Woodhouse schrieb:
> On Wed, 2003-06-11 at 17:03, Steven Scholz wrote:
> 
>>Is it safe to just do a
>>
>>~ # kill -s SIGSTOP `pidof jffs2_gcd_mtd0`
>>
>>even if my root fs is on this JFFS2 partition?
> 
> 
> Yes.
> 
> 
>>(I just tried it now and it seems to work. But IIRC a while ago my 
>>system hung when I did something like that...)
> 
> 
> It shouldn't. The GC thread remains strictly an optimisation (and
> doesn't exist in the eCos port, etc.)
> 

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

Re: Stopping the GC thread?

[David Woodhouse]

On Thu, 2003-06-12 at 10:08, Steven Scholz wrote:
> 1.) What happens if I send multiple SIGSTOPs or SIGCONTs to the 
> thread? Does she handle (i.e. ignore) that properly?

Should do.

> 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?

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.

> I suppose that a few more sectors will be examened and written... 
> (10ms, 100ms, 1000ms ...???)

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

> Will it then just continue after a SIGCONT? Or will start all over again?

It'll just continue.

-- 
dwmw2

Re: Stopping the GC thread?

[Steven Scholz]

David,

>>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?
> 
> 
> 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.

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 suppose that a few more sectors will be examened and written... 
>>(10ms, 100ms, 1000ms ...???)
> 
> 
> 'sector'?  Read http://sources.redhat.com/jffs2/jffs2.pdf 
I meant flash sectors.

Steven

Re: Stopping the GC thread?

[David Woodhouse]

On Thu, 2003-06-12 at 10:35, Steven Scholz wrote:

> 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?

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

> >>I suppose that a few more sectors will be examened and written... 
> >>(10ms, 100ms, 1000ms ...???)

> > 'sector'?  Read http://sources.redhat.com/jffs2/jffs2.pdf
> I meant flash sectors.

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

Re: Stopping the GC thread?

[Jörn Engel]

On Thu, 12 June 2003 11:35:59 +0200, Steven Scholz wrote:
> 
> 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?

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).

> >'sector'?  Read http://sources.redhat.com/jffs2/jffs2.pdf 
> I meant flash sectors.

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