Re: [tcf-dev] The profiler service

[Kodikal Sidharth-R1AAKB <R1AAKB@xxxxxxxxxxxxx>]

Hi Eugene,

Thanks for replying.

> You supposed to use the Processes service to start/attach/suspend a process. The service will return the context ID. While the process is suspended, you can configure profiling and/or add any other instrumentation, like breakpoints, then you resume the process.

I understand that a client would use the Processes services to start a process (in the attached mode) and then likely use the RunControl service to suspend the process. My question was in case a client wants to profile a process from the very beginning.
The process will likely have executed a bit before it is suspended, or is that not the case?

> A "push" protocol, like sending events when data is available, would require some form of flow control (aka throttling or back pressure), which is more complicated than a "pull" protocol (like polling), and, in general, it is not necessarily more efficient. It make sense if data not available for long periods of time, but this is usually not true for profiling/tracing. I would prefer to keep it simple, at least for now.

I agree that simple is better in general.
In my case, I have scenarios such as "trace program flow if/when PC on core x in a certain address range" or "count events if/ when DDR traffic from a specific hardware accelerator is in a certain range" - scenarios that don't necessarily continually generate data.
For an SoC with many contexts (several cores, accelerators etc.), polling may not be ideal for me.

Regards,
Sidharth


-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Eugene Tarassov
Sent: Monday, May 06, 2013 12:33 PM
To: TCF Development
Subject: Re: [tcf-dev] The profiler service

Hi Sidharth,

> If I wanted to start a process and profile it from the beginning, what debug context would I pass in to the configure command?

You supposed to use the Processes service to start/attach/suspend a process. The service will return the context ID. While the process is suspended, you can configure profiling and/or add any other instrumentation, like breakpoints, then you resume the process.

> I suppose to disable just one of those profilers, I could encode that choice into params?

Different profilers are supposed to use different subsets of configuration attributes. To disable a profiler you modify (e.g. remove) attributes that control that profiler, then re-submit the configuration.

> I suppose one could configure different profilers on different channels if necessary

Yes.

> Would be nice to have an event to notify the client that data is available to be read (instead of having the client poll)

A "push" protocol, like sending events when data is available, would require some form of flow control (aka throttling or back pressure), which is more complicated than a "pull" protocol (like polling), and, in general, it is not necessarily more efficient. It make sense if data not available for long periods of time, but this is usually not true for profiling/tracing. I would prefer to keep it simple, at least for now.

Regards,
Eugene

-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Kodikal Sidharth-R1AAKB
Sent: Friday, May 03, 2013 3:21 PM
To: tcf-dev@xxxxxxxxxxx
Subject: [tcf-dev] The profiler service

Hi Eugene,

I started to look at the newly added profiler service and it looks nicely generic and extensible.

A couple of initial thoughts and questions please:

If I wanted to start a process and profile it from the beginning, what debug context would I pass in to the configure command?

There can potentially be multiple profilers registered/configured for a debug context.
To disable all profilers, invoking the configure command with empty or null params will work.
I suppose to disable just one of those profilers, I could encode that choice into params?
Similarly for the read command, could be useful to disambiguate between the different profilers for a context.
(I suppose one could configure different profilers on different channels if necessary)

Would be nice to have an event to notify the client that data is available to be read (instead of having the client poll)

Finally, like Anna, I too vote, fwiw, for an implementation based on perf :)

Thanks,
Sidharth

_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.


_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev