Hi,
On 08/27/2014 02:39 AM, Chris Johns wrote:
On 27/08/2014 3:50 am, Jennifer Averett wrote:
> We suggest to remove the ref_count of the task structures to save
> time and locking. Otherwise we need atomic counters here?
You need a means of tracking the logged references to the task data in the
trace log. The log can exist well past the life time of the task and the data.
Yes, I thought that was inline with what we suggested.
> We suggest to free task structures when reading, by recording time of
> task deletion event we know when last event referencing the task
occurred,
I do not like this approach.
Allocating and freeing memory in the trace recording path introduces jitter in
adding records, it requires taking a SMP lock.
> when that time have passed it should be okay to free the task structure?
Can anyone see a problem with this. My question is will this always
work based on the zombie state of the thread? I thought I saw
You cannot remove the ref_counts without an equivalent. The data is referenced
beyond the life of a task.
Do you mean that there will be references to the task struct after the task
delete record has been read? I assumed that the task delete was the last record
referencing the task struct?
Another approach could involve adding the task data to the trace buffer when the first reference to the task is added to the trace buffer. You would add the task data tagging it with some sort of
"id". When added events related to the task the "id" is used. The trace buffer decoder extracts the task data building a suitable table to decode the following "id" references. There is a small
extra bump filling the trace buffer with the task details but this is the cost of tracing in software. This approach helps solves the problem of off board streaming of the trace data.
I like this approach much better, but I assumed it would be harder to
implement. Then we could basically remove the task struct.. That would solve
allocation/freeing of the task structs too?
Thanks,
Daniel Hellstrom
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
