|
From: Tom D. <tom...@vs...> - 2007-11-22 10:31:09
|
Hello, I would like to make an application which shows each of an application task on a timeline, and shows when the tasks were activated, like this: pid 1000 --____--_-_____ pid 1001 __--________-__ pid 1002 ____--__-_--___ idle _____________-- ticks 0----5---10---15 so I need to record the taskswitches for the one application, so I would want a list of tasks with a timestamp or a tick count when the task was activated, and when deactivated, and also on which processor that the task was scheduled. Is this already possible with valgrind? It would be nice to monitor multithreaded behaviour of my application. Best regards, Tom, |
|
From: Tom H. <to...@co...> - 2007-11-22 11:37:54
|
On Nov 22, 2007 10:31 AM, Tom Deblauwe <tom...@vs...> wrote: > I would like to make an application which shows each of an application > task on a timeline, and shows when the tasks were activated, like this: > > pid 1000 --____--_-_____ > pid 1001 __--________-__ > pid 1002 ____--__-_--___ > idle _____________-- > > ticks 0----5---10---15 > > so I need to record the taskswitches for the one application, so I would > want a list of tasks with a timestamp or a tick count when the task was > activated, and when deactivated, and also on which processor that the > task was scheduled. Is this already possible with valgrind? It would be > nice to monitor multithreaded behaviour of my application. What do you mean by "task" here? Do you mean processes or threads within a process? Either way the behaviour under valgrind will be so different to normal that it is probably of little use to you. That said neither case is going to be particularly deterministic anyway, regardless of whether or not you are running under valgrind, unless you use locks to make it so. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Tom D. <tom...@vs...> - 2007-11-22 15:33:25
|
Tom Hughes wrote: > What do you mean by "task" here? Do you mean processes or threads > within a process? > > Either way the behaviour under valgrind will be so different to normal > that it is probably of little use to you. That said neither case is > going to be particularly deterministic anyway, regardless of whether > or not you are running under valgrind, unless you use locks to make it > so. > > Hello Tom, I mean threads within a process. So it would require a new valgrind tool which only records thread switches for a certain process, there is too much data that is collected maybe with for example callgrind? No option to collect only the info I am talking about? In the embedded system I was using previously, you could give a function pointer and then that would be called between task switches so I could easily record the ticks and taskid on every taskswitch in a memory buffer without too much overhead, and then when that memory buffer was full, I would start a task from within that taskswitch function and save the buffer to disk. So that's what I was checking now, how I would do this sort of thing on linux. I'll check callgrind's sources maybe for a clue. Thanks, Tom, |
|
From: Tom H. <to...@co...> - 2007-11-22 16:52:08
|
In message <474...@vs...>
Tom Deblauwe <tom...@vs...> wrote:
> Tom Hughes wrote:
>
>> What do you mean by "task" here? Do you mean processes or threads
>> within a process?
>>
>> Either way the behaviour under valgrind will be so different to normal
>> that it is probably of little use to you. That said neither case is
>> going to be particularly deterministic anyway, regardless of whether
>> or not you are running under valgrind, unless you use locks to make it
>> so.
>
> I mean threads within a process.
> So it would require a new valgrind tool which only records thread
> switches for a certain process, there is too much data that is
> collected maybe with for example callgrind? No option to collect only
> the info I am talking about?
No such option, and because valgrind switches threads in a completely
different way to the normal operating system it won't help you much
to know what happens under valgrind.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|