From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932228AbdGJNrI (ORCPT ); Mon, 10 Jul 2017 09:47:08 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:59784 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932137AbdGJNrH (ORCPT ); Mon, 10 Jul 2017 09:47:07 -0400 Date: Mon, 10 Jul 2017 15:46:58 +0200 From: Peter Zijlstra To: Segher Boessenkool Cc: "Jin, Yao" , Michael Ellerman , acme@kernel.org, jolsa@kernel.org, mingo@redhat.com, alexander.shishkin@linux.intel.com, kan.liang@intel.com, ak@linux.intel.com, linuxppc-dev@lists.ozlabs.org, Linux-kernel@vger.kernel.org, yao.jin@intel.com Subject: Re: [PATCH v6 1/7] perf/core: Define the common branch type classification Message-ID: <20170710134658.k44bpa7tra2woyiu@hirez.programming.kicks-ass.net> References: <1492690075-17243-1-git-send-email-yao.jin@linux.intel.com> <1492690075-17243-2-git-send-email-yao.jin@linux.intel.com> <87r2xoj08g.fsf@concordia.ellerman.id.au> <820424b8-d7b3-56cc-2b97-ec570d44ec25@linux.intel.com> <87h8ykvayi.fsf@concordia.ellerman.id.au> <20170710131049.GA13471@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170710131049.GA13471@gate.crashing.org> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 10, 2017 at 08:10:50AM -0500, Segher Boessenkool wrote: > > PERF_BR_INT is triggered by instruction "int" . > > PERF_BR_IRQ is triggered by interrupts, traps, faults (the ring 0,3 > > transition). > > So your "PERF_BR_INT" is a system call? The "INT" thing has indeed been used as system call mechanism (typically INT 80). But these days we have special purpose syscall instructions. It could maybe be compared to the PPC "Unconditional TRAP with immediate" where you use the immediate value as an index into a handler vector. > And PERF_BR_IRQ is not an interrupt request (as its name suggests), > not what we call an "external interrupt" either; instead it is every > interrupt that is not a system call? It is actual interrupts, but also faults, traps and all the other exceptions not caused by "INT" I think.