Task madness - can we do some cleanup?

Started by g3gg0, August 15, 2013, 11:49:41 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

g3gg0

Hi,

this time i am requesting collaboration to analyze and clean up our task chaos.

When investigating the performance drop of CF writing in photo mode compared to playback mode,
which causes up to 7MiB/s less transfer speed, i recorded a timing trace of all task and ISR activations.
What annoyed me, was the endless number of tasks for various more and less important things.

Let me show you a trace (please scroll horizontally using cursor keys in your browser):


I marked all ML tasks in red on the left column.
The horizontal axis is the execution time of course.
A red bar means, this item (task/ISR) is being executed at this time. If the activation is very short, you just see a black bar.

Zooming into two activations of ML tasks:


There you see that the tasks are running very short. Only a few microseconds.



But even this short activation period costs execution time - about 2 * 10 microseconds for switching the tasks.
Sometimes this is totally unnecessary and we could save CPU execution time, battery power and maybe write performance for raw recording.
For example the joypress task that takes ~15µs execution time plus 10µs context switch time every 20ms for nothing?
I never press the joystick, so why do i have to sacrifice 0.1% of the execution time?
Sum up all 30 tasks and this is at least 3% that might be unnecessary (yeah, in theory ;) )

Some bad thing is, that the context switches will take longer, the more tasks are waiting to get activated.
At the moment some of the "unnecessary" msleep-polling costs 924µs according to the image above.
Thats a milisecond that is causing delay to other tasks that *really* have to process stuff.
Also the CF write rate seems to go down due to those activations.

So can we try to investigate task by task,
a) if we really need that task
b) if it really has to msleep(x) for just polling a variable
c) if the thing the task does can be achieved with timeout-less message queues

This is not a one-day task, but an ongoing process that may take weeks to clean up.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Marsu42

Quote from: g3gg0 on August 15, 2013, 11:49:41 PM
So can we try to investigate task by task,
a) if we really need that task
b) if it really has to msleep(x) for just polling a variable
c) if the thing the task does can be achieved with timeout-less message queues

Great idea to have a go at this, I wondered about the necessity of all these tasks myself but would never have dared to say so being just a humble ml enthusiast :-) ... possible task to drop right away would be the audio tasks if you don't do audio at all.

ilguercio

Will this influence SD based models as well?
I read somewhere that the SD controller in the 6D is capable of 50MB/s but it only delivers 40-41MB/s.
Canon EOS 6D, 60D, 50D.
Sigma 70-200 EX OS HSM, Sigma 70-200 Apo EX HSM, Samyang 14 2.8, Samyang 35 1.4, Samyang 85 1.4.
Proud supporter of Magic Lantern.

g3gg0

Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

mucher

The power management thread seemingly keeps tremendous amount of CPU cycle to itself. There might be some ways to stop the power saving thread while running ML tasks, because the camera is running tasks, no point to do power saving.

nanomad

It's probably the same as the idle task in windows, used to make the ARM cpu enter a low power saving mode. One thing we can try is reducing the number of trivial ML tasks by using callbacks instead.
EOS 1100D | EOS 650 (No, I didn't forget the D) | Ye Olde Canon EF Lenses ('87): 50 f/1.8 - 28 f/2.8 - 70-210 f/4 | EF-S 18-55 f/3.5-5.6 | Metz 36 AF-5

g3gg0

Quote from: nanomad on August 17, 2013, 04:15:45 PM
It's probably the same as the idle task in windows, used to make the ARM cpu enter a low power saving mode. One thing we can try is reducing the number of trivial ML tasks by using callbacks instead.

or better: message queues.
we have the stubs for all models already.
and a message queue design makes a lot of things easier to handle :)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!