Page MenuHomeFreeBSD

hwpmc : pmc start is delayed until a context switch occurs
Needs ReviewPublic

Authored by shreyankamartya229_gmail.com on Dec 23 2019, 4:29 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Apr 8, 9:08 PM
Unknown Object (File)
Mon, Apr 8, 8:34 PM
Unknown Object (File)
Dec 20 2023, 5:13 AM
Unknown Object (File)
Nov 17 2023, 9:50 PM
Unknown Object (File)
Nov 17 2023, 9:12 PM
Unknown Object (File)
Aug 18 2023, 3:26 PM
Unknown Object (File)
Aug 10 2023, 4:16 PM
Unknown Object (File)
May 11 2023, 4:26 AM
Subscribers

Details

Reviewers
markj
mmacy
Summary

At times, while trying to profile an already running process with pmcstat (-t <pid>), output file contains no samples. Looking at the hwpmc debug logs it seems like in this scenario pmc start is delayed until a target process context switch occurs or doesn't happen at all.

pmc_start() relies on a forced context switch to set the pmc hardware state in case the pmc is attached to its owner process. But in case pmc is not attached to its owner process (i.e when profiling another target process), pmc_start returns without setting the pmc hardware state.

Test Plan

Tested the patch on amd64 platform.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

sys/dev/hwpmc/hwpmc_mod.c
3188

I don't really understand why this change makes a difference. If we have attached to a different process, then PMCATTACH should have placed the target process in the pm_targets list before the PMC was started. In that case we should have error == 0 here, so the change is a no-op.

Reading the description, it sounds like the target process is never yielding the CPU and so it never enables the PMC. I don't see how this change helps though. What am I missing?

sys/dev/hwpmc/hwpmc_mod.c
3188

You are right. this makes no difference (sorry about that). What I intended was for the "return (error)" to be inside the "if (pm->pm_flags & PMC_F_ATTACHED_TO_OWNER)" block so that the control falls to the bottom of the pmc_start() function where we write and start the pmc. However, being a process virtual pmc it is not attached to a specific cpu so that wouldn't work.

Any ideas on how I could go about trying to fix this problem?

The ways I can think of are: somehow make the target process switch context(not very sure if that is possible) or start the pmc for the cpu on which target process is running (Add a block to handle this case in pmc_start()).

sys/dev/hwpmc/hwpmc_mod.c
3188

Assuming that this indeed the problem, you could try using the smp_rendezvous() KPI to interrupt the threads running the target process, and enable the PMC in the rendezvous handler.