All of lore.kernel.org
 help / color / mirror / Atom feed
From: Song Liu <songliubraving@fb.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "open list:BPF (Safe dynamic programs and tools)" 
	<bpf@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, kajoljain <kjain@linux.ibm.com>,
	Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH v2 bpf-next 1/3] perf: enable branch record for software events
Date: Mon, 30 Aug 2021 16:06:30 +0000	[thread overview]
Message-ID: <FBD95188-A9A3-4D0C-ACCD-650BAE772879@fb.com> (raw)
In-Reply-To: <20210830104334.GJ4353@worktop.programming.kicks-ass.net>



> On Aug 30, 2021, at 3:43 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> 
> On Thu, Aug 26, 2021 at 03:13:04PM -0700, Song Liu wrote:
> 
>> Some data on intel_pmu_lbr_disable_all() and perf_pmu_disable().
>> 
>> With this patch, when fexit program triggers, intel_pmu_lbr_disable_all is
>> used to stop the LBR, and the LBR is stopped after 6 extra branch records
>> (see the full trace below). If we replace intel_pmu_lbr_disable_all in
>> intel_pmu_snapshot_branch_stack() with perf_pmu_disable, the LBR is stopped
>> after 19 extra branch records. This is still acceptable for systems with 32
>> LBR entries. But for systems with fewer entries, all the entries before
>> fexit are flushed. Therefore, I suggest we take the short cut and stop LBR
>> asap.
>> 
>> 
>> LBR snapshot captured when we use intel_pmu_lbr_disable_all():
>> 
>> ID: 0 from intel_pmu_lbr_disable_all.part.10+37 to intel_pmu_lbr_disable_all.part.10+72
>> ID: 1 from intel_pmu_lbr_disable_all.part.10+33 to intel_pmu_lbr_disable_all.part.10+37
>> ID: 2 from intel_pmu_snapshot_branch_stack+51 to intel_pmu_lbr_disable_all.part.10+0
>> ID: 3 from __bpf_prog_enter+53 to intel_pmu_snapshot_branch_stack+0
>> ID: 4 from __bpf_prog_enter+8 to __bpf_prog_enter+38
>> ID: 5 from __brk_limit+473903158 to __bpf_prog_enter+0
>> ID: 6 from bpf_fexit_loop_test1+22 to __brk_limit+473903139
>> ID: 7 from bpf_fexit_loop_test1+20 to bpf_fexit_loop_test1+13
>> ID: 8 from bpf_fexit_loop_test1+20 to bpf_fexit_loop_test1+13
>> ID: 9 from bpf_fexit_loop_test1+20 to bpf_fexit_loop_test1+13
>> 
>> 
>> LBR snapshot captured when we use perf_pmu_disable():
>> 
>> ID: 0 from intel_pmu_lbr_disable_all+58 to intel_pmu_lbr_disable_all+93
>> ID: 1 from intel_pmu_lbr_disable_all+54 to intel_pmu_lbr_disable_all+58
>> ID: 2 from intel_pmu_disable_all+15 to intel_pmu_lbr_disable_all+0
>> ID: 3 from intel_pmu_pebs_disable_all+30 to intel_pmu_disable_all+15
>> ID: 4 from intel_pmu_disable_all+10 to intel_pmu_pebs_disable_all+0
>> ID: 5 from __intel_pmu_disable_all+49 to intel_pmu_disable_all+10
>> ID: 6 from intel_pmu_disable_all+5 to __intel_pmu_disable_all+0
>> ID: 7 from x86_pmu_disable+61 to intel_pmu_disable_all+0
>> ID: 8 from x86_pmu_disable+38 to x86_pmu_disable+41
>> ID: 9 from __x86_indirect_thunk_rax+16 to x86_pmu_disable+0
>> ID: 10 from __x86_indirect_thunk_rax+0 to __x86_indirect_thunk_rax+12
>> ID: 11 from perf_pmu_disable.part.122+4 to __x86_indirect_thunk_rax+0
>> ID: 12 from perf_pmu_disable+23 to perf_pmu_disable.part.122+0
>> ID: 13 from intel_pmu_snapshot_branch_stack+45 to perf_pmu_disable+0
>> ID: 14 from x86_get_pmu+35 to intel_pmu_snapshot_branch_stack+39
>> ID: 15 from intel_pmu_snapshot_branch_stack+34 to x86_get_pmu+0
>> ID: 16 from __bpf_prog_enter+53 to intel_pmu_snapshot_branch_stack+0
>> ID: 17 from __bpf_prog_enter+8 to __bpf_prog_enter+38
>> ID: 18 from __brk_limit+478056502 to __bpf_prog_enter+0
>> ID: 19 from bpf_fexit_loop_test1+22 to __brk_limit+478056483
>> ID: 20 from bpf_fexit_loop_test1+20 to bpf_fexit_loop_test1+13
>> ID: 21 from bpf_fexit_loop_test1+20 to bpf_fexit_loop_test1+13
> 
> Well, if you're willing to do something like:
> 
>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>> index ac6fd2dabf6a2..a29649e7241cc 100644
>> --- a/arch/x86/events/intel/core.c
>> +++ b/arch/x86/events/intel/core.c
>> @@ -6283,8 +6283,11 @@ __init int intel_pmu_init(void)
>> 			x86_pmu.lbr_nr = 0;
>> 	}
>> 
>> -	if (x86_pmu.lbr_nr)
>> +	if (x86_pmu.lbr_nr) {
>> 		pr_cont("%d-deep LBR, ", x86_pmu.lbr_nr);
> 
> 		if (x86_pmu.disable_all == intel_pmu_disable_all)
> 
>> +		static_call_update(perf_snapshot_branch_stack,
>> +				   intel_pmu_snapshot_branch_stack);
>> +	}
>> 
>> 	intel_pmu_check_extra_regs(x86_pmu.extra_regs);
>> 
>> diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
>> index 9e6d6eaeb4cb6..7d4fe1d6e79ff 100644
>> --- a/arch/x86/events/intel/lbr.c
>> +++ b/arch/x86/events/intel/lbr.c
>> @@ -1862,3 +1862,16 @@ EXPORT_SYMBOL_GPL(x86_perf_get_lbr);
>> struct event_constraint vlbr_constraint =
>> 	__EVENT_CONSTRAINT(INTEL_FIXED_VLBR_EVENT, (1ULL << INTEL_PMC_IDX_FIXED_VLBR),
>> 			  FIXED_EVENT_FLAGS, 1, 0, PERF_X86_EVENT_LBR_SELECT);
>> +
>> +int intel_pmu_snapshot_branch_stack(struct perf_branch_snapshot *br_snapshot)
>> +{
>> +	struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
>> +
>> +	intel_pmu_lbr_disable_all();
>> +	intel_pmu_lbr_read();
>> +	memcpy(br_snapshot->entries, cpuc->lbr_entries,
>> +	       sizeof(struct perf_branch_entry) * x86_pmu.lbr_nr);
>> +	br_snapshot->nr = x86_pmu.lbr_nr;
>> +	intel_pmu_lbr_enable_all(false);
>> +	return 0;
>> +}
> 
> Then the above can assume perfmon > v2 and we can either inline
> __intel_pmu_disable_all() or simply do the
> wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL).

I think can do perfmon > v2 only. 

> 
> One thing that needs checking, intel_pmu_disable_all() also clears
> MSR_IA32_PEBS_ENABLE, is that really needed if we just want to inhibit
> PMIs ? That is, will the PEBS machinery still trigger PMI if GLOBAL_CTRL
> == 0 ?

Actually, can we do something like:

static void intel_pmu_disable_all(void)
{
        intel_pmu_lbr_disable_all();   /* moved to the beginning */
        __intel_pmu_disable_all();
        intel_pmu_pebs_disable_all();
}

int intel_pmu_snapshot_branch_stack(struct perf_branch_snapshot *br_snapshot)
{
        struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);

	
        intel_pmu_disable_all();   /* call full pmu_disable */
        intel_pmu_lbr_read();
        memcpy(br_snapshot->entries, cpuc->lbr_entries,
               sizeof(struct perf_branch_entry) * x86_pmu.lbr_nr);
        br_snapshot->nr = x86_pmu.lbr_nr;

        intel_pmu_enable_all(false);
        return 0;
}

In this way, we still call intel_pmu_disable_all(), but since LBR is disabled 
at the beginning of it, we would not flush too many LBR entries. 

Thanks,
Song

  reply	other threads:[~2021-08-30 16:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-26 22:13 [PATCH v2 bpf-next 0/3] bpf: introduce bpf_get_branch_snapshot Song Liu
2021-08-26 22:13 ` [PATCH v2 bpf-next 1/3] perf: enable branch record for software events Song Liu
2021-08-30 10:22   ` Peter Zijlstra
2021-08-30 15:25     ` Song Liu
2021-08-30 16:06       ` Peter Zijlstra
2021-08-30 16:36         ` Song Liu
2021-09-01 17:09           ` Peter Zijlstra
2021-08-30 17:41     ` Song Liu
2021-08-30 18:07       ` Peter Zijlstra
2021-09-01 17:12         ` Peter Zijlstra
2021-09-04 23:01           ` Josh Poimboeuf
2021-08-30 10:43   ` Peter Zijlstra
2021-08-30 16:06     ` Song Liu [this message]
2021-08-26 22:13 ` [PATCH v2 bpf-next 2/3] bpf: introduce helper bpf_get_branch_snapshot Song Liu
2021-08-27  9:28   ` kernel test robot
2021-08-27  9:28     ` kernel test robot
2021-08-27 15:10   ` kernel test robot
2021-08-27 15:10     ` kernel test robot
2021-08-30 10:47     ` Peter Zijlstra
2021-08-30 10:47       ` Peter Zijlstra
2021-08-26 22:13 ` [PATCH v2 bpf-next 3/3] selftests/bpf: add test for bpf_get_branch_snapshot Song Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=FBD95188-A9A3-4D0C-ACCD-650BAE772879@fb.com \
    --to=songliubraving@fb.com \
    --cc=Kernel-team@fb.com \
    --cc=acme@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=kjain@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.