On August 27, 2014 7:33:28 AM CDT, Daniel Hellstrom <dan...@gaisler.com> wrote: >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?
This is impossible or at least very complicated to implement. The trace buffers are a circular queue and you would end up with gaps in the middle which would have to be preserved across reads of records and wrapping. Using an id may require a global lock but we can use the same basic algorithm as the id look up and be deterministic. > >Thanks, >Daniel Hellstrom > >_______________________________________________ >devel mailing list >devel@rtems.org >http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
