[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tcf-dev] The profiler service
|
Hi Sidharth,
> Btw, I have documented the Profiler service protocol for my own use.
> I can submit it if anybody else needs it.
Contributions are always welcome. Please (always) feel free to submit a gerrit change if extending and/or updating files.
Thanks, Best regards, Uwe :)
> -----Original Message-----
> From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Kodikal
> Sidharth-R1AAKB
> Sent: Donnerstag, 09. Mai 2013 18:53
> To: TCF Development
> Subject: 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
>
>
> _______________________________________________
> tcf-dev mailing list
> tcf-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/tcf-dev
