[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tcf-dev] The profiler service
|
Hi Eugene,
Thanks for the clarification.
It was perhaps implied in the processes service protocol definition, but it wasn't clear to me that starting a process (in attached mode?) suspends the process at the entry point.
Perhaps worth mentioning.
> In scenarios that don't generate data continually, agent is supposed to delay response to "read" command until data is available.
Ok, I can go with that. I suppose a client would cancel such a potentially long-standing read request, if necessary, by un-configuring the profiler?
Btw, I have documented the Profiler service protocol for my own use.
I can submit it if anybody else needs it.
Regards,
Sidharth
-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Eugene Tarassov
Sent: Tuesday, May 07, 2013 11:43 AM
To: TCF Development
Subject: Re: [tcf-dev] The profiler service
Hi Sidharth,
> The process will likely have executed a bit before it is suspended, or is that not the case?
No, that is not the case. The process will be suspended at entry address when it is created. Then RunControl service can be used to resume the process.
> For an SoC with many contexts (several cores, accelerators etc.), polling may not be ideal for me.
In scenarios that don't generate data continually, agent is supposed to delay response to "read" command until data is available. Such protocol can automatically balance amount of data and bandwidth: client would delay sending "read" command if agent produces too much data, allowing agent to drop extra data or reduce sampling speed, agent would delay responding to the command if too little or no data is available.
Regards,
Eugene
-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Kodikal Sidharth-R1AAKB
Sent: Tuesday, May 07, 2013 7:36 AM
To: TCF Development
Subject: Re: [tcf-dev] The profiler service
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
_______________________________________________
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
