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):
(http://upload.g3gg0.de/pub_files/30440a465686fa001e0f0340b68d9230/TskMonTrace.png)
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:
(http://upload.g3gg0.de/pub_files/8a040da7e607fc01245f001c6330f429/TskMonTrace2.png)
There you see that the tasks are running very short. Only a few microseconds.
(http://upload.g3gg0.de/pub_files/36c0111c307eddc850106477d109efcb/TskMonTrace3.png)
(http://upload.g3gg0.de/pub_files/16222701d41374e945ae8c7d32660c88/TskMonTrace4.png)
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.
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.
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.
Quote from: ilguercio on August 16, 2013, 07:06:41 AM
Will this influence SD based models as well?
i think only very little.
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.
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.
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 :)