From: Zong Li <zong.li@sifive.com> To: Alan Kao <alankao@andestech.com> Cc: Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>, linux-riscv <linux-riscv@lists.infradead.org>, "linux-kernel@vger.kernel.org List" <linux-kernel@vger.kernel.org> Subject: Re: [RFC PATCH 0/6] Support raw event and DT for perf on RISC-V Date: Wed, 1 Jul 2020 11:15:27 +0800 [thread overview] Message-ID: <CANXhq0o322Pa1kUXjBb4b21Zxrz+zXB5D7Ljyj18j_=TMKfeVg@mail.gmail.com> (raw) In-Reply-To: <20200701005129.GA27962@andestech.com> On Wed, Jul 1, 2020 at 8:52 AM Alan Kao <alankao@andestech.com> wrote: > > On Mon, Jun 29, 2020 at 11:19:09AM +0800, Zong Li wrote: > > This patch set adds raw event support on RISC-V. In addition, we > > introduce the DT mechanism to make our perf more generic and common. > > > > Currently, we set the hardware events by writing the mhpmeventN CSRs, it > > would raise an illegal instruction exception and trap into m-mode to > > emulate event selector CSRs access. It doesn't make sense because we > > shouldn't write the m-mode CSRs in s-mode. Ideally, we should set event > > selector through standard SBI call or the shadow CSRs of s-mode. We have > > prepared a proposal of a new SBI extension, called "PMU SBI extension", > > but we also discussing the feasibility of accessing these PMU CSRs on > > s-mode at the same time, such as delegation mechanism, so I was > > wondering if we could use SBI calls first and make the PMU SBI extension > > as legacy when s-mode access mechanism is accepted by Foundation? or > > keep the current situation to see what would happen in the future. > > > > This patch set also introduces the DT mechanism, we don't want to add too > > much platform-dependency code in perf like other architectures, so we > > put the mapping of generic hardware events to DT, then we can easy to > > transfer generic hardware events to vendor's own hardware events without > > any platfrom-dependency stuff in our perf. > > > > Zong Li (6): > > dt-bindings: riscv: Add YAML documentation for PMU > > riscv: dts: sifive: Add DT support for PMU > > riscv: add definition of hpmcounter CSRs > > riscv: perf: Add raw event support > > riscv: perf: introduce DT mechanism > > riscv: remove PMU menu of Kconfig > > > > DT-based PMU registration looks good to me. Together with Anup's feedback, > we can anticipate that the following items will be: > > - rewrite RISC-V PMU to a platform driver > - propose SBI PMU extention > - fixes: RV32 counter access, namings, etc. > > Yes, all are good directions towards better counting (`perf stat`) function. > But as the original author of RISC-V perf port, please allow me to address > the fundamental problems of RISC-V perf, again [0][1][2][3], that the sampling > (`perf record`) function never earned enough respect. Counting gives you a > shallow view regarding an application, while sampling demystifies one for you. > > The problems are three-fold > (1) Interrupt > Sampling in perf requires that a HPM raises an interrupt when it overflows. > Making RISC-V perf platform driver or not has nothing to do with this. This > requires more discussions in TGs. > (2) S-mode access to PMU CSRs > This is also addressed in this patch set but to me, it is kind of like a > SBI-solves-them-all mindset to me. Perf event is for performance monitoring > thus we should eliminate any possible overhead if we can. Setting event masks > through SBI calls for counting maybe OK, but if we really take sampling and > interrupt handling into consideration, it is questionable if it is still a > viable way. > (3) Registers, registers, registers > There is just no enough CSR/function for perf sampling. The previous proposal > explains why [2]. > > Perf sampling is off-topic but somehow related, so I bring it up here just > for your information. > Agree, sampling is an important measurement for perf, we should integrate it to perf as soon as possible after overflow interrupt mechanism is standardized. > As this patch set goes v2, the PMU porting guide in [0] should be removed since > it contains no useful information anymore. > It seems that the document mentioned some hook functions, it is good for me to reserve this document, maybe we could try to give some modification. I would check that. Thanks > [0] Documentation/riscv/pmu.rst > [1] https://www.youtube.com/watch?v=Onvlcl4e2IU > [2] https://github.com/riscv/riscv-isa-manual/issues/402 > This proposal has been posted in Privileged Spec Task Group, in > https://lists.riscv.org/g/tech-privileged-archive/message/488?p=,,,20,0,0,0::Created,,Proposal,20,2,40,32306071 > but never receive any feedback. > [3] https://lists.riscv.org/g/tech-unixplatformspec/message/84 > I intended to discuss [2] in the Unixplatform Spec Task Group at the > online meeting, but obviously people were too busy knowing who the new > RISC-V CTO is and what he has done to even follow the agenda. >
WARNING: multiple messages have this Message-ID (diff)
From: Zong Li <zong.li@sifive.com> To: Alan Kao <alankao@andestech.com> Cc: linux-riscv <linux-riscv@lists.infradead.org>, Palmer Dabbelt <palmer@dabbelt.com>, "linux-kernel@vger.kernel.org List" <linux-kernel@vger.kernel.org>, Paul Walmsley <paul.walmsley@sifive.com> Subject: Re: [RFC PATCH 0/6] Support raw event and DT for perf on RISC-V Date: Wed, 1 Jul 2020 11:15:27 +0800 [thread overview] Message-ID: <CANXhq0o322Pa1kUXjBb4b21Zxrz+zXB5D7Ljyj18j_=TMKfeVg@mail.gmail.com> (raw) In-Reply-To: <20200701005129.GA27962@andestech.com> On Wed, Jul 1, 2020 at 8:52 AM Alan Kao <alankao@andestech.com> wrote: > > On Mon, Jun 29, 2020 at 11:19:09AM +0800, Zong Li wrote: > > This patch set adds raw event support on RISC-V. In addition, we > > introduce the DT mechanism to make our perf more generic and common. > > > > Currently, we set the hardware events by writing the mhpmeventN CSRs, it > > would raise an illegal instruction exception and trap into m-mode to > > emulate event selector CSRs access. It doesn't make sense because we > > shouldn't write the m-mode CSRs in s-mode. Ideally, we should set event > > selector through standard SBI call or the shadow CSRs of s-mode. We have > > prepared a proposal of a new SBI extension, called "PMU SBI extension", > > but we also discussing the feasibility of accessing these PMU CSRs on > > s-mode at the same time, such as delegation mechanism, so I was > > wondering if we could use SBI calls first and make the PMU SBI extension > > as legacy when s-mode access mechanism is accepted by Foundation? or > > keep the current situation to see what would happen in the future. > > > > This patch set also introduces the DT mechanism, we don't want to add too > > much platform-dependency code in perf like other architectures, so we > > put the mapping of generic hardware events to DT, then we can easy to > > transfer generic hardware events to vendor's own hardware events without > > any platfrom-dependency stuff in our perf. > > > > Zong Li (6): > > dt-bindings: riscv: Add YAML documentation for PMU > > riscv: dts: sifive: Add DT support for PMU > > riscv: add definition of hpmcounter CSRs > > riscv: perf: Add raw event support > > riscv: perf: introduce DT mechanism > > riscv: remove PMU menu of Kconfig > > > > DT-based PMU registration looks good to me. Together with Anup's feedback, > we can anticipate that the following items will be: > > - rewrite RISC-V PMU to a platform driver > - propose SBI PMU extention > - fixes: RV32 counter access, namings, etc. > > Yes, all are good directions towards better counting (`perf stat`) function. > But as the original author of RISC-V perf port, please allow me to address > the fundamental problems of RISC-V perf, again [0][1][2][3], that the sampling > (`perf record`) function never earned enough respect. Counting gives you a > shallow view regarding an application, while sampling demystifies one for you. > > The problems are three-fold > (1) Interrupt > Sampling in perf requires that a HPM raises an interrupt when it overflows. > Making RISC-V perf platform driver or not has nothing to do with this. This > requires more discussions in TGs. > (2) S-mode access to PMU CSRs > This is also addressed in this patch set but to me, it is kind of like a > SBI-solves-them-all mindset to me. Perf event is for performance monitoring > thus we should eliminate any possible overhead if we can. Setting event masks > through SBI calls for counting maybe OK, but if we really take sampling and > interrupt handling into consideration, it is questionable if it is still a > viable way. > (3) Registers, registers, registers > There is just no enough CSR/function for perf sampling. The previous proposal > explains why [2]. > > Perf sampling is off-topic but somehow related, so I bring it up here just > for your information. > Agree, sampling is an important measurement for perf, we should integrate it to perf as soon as possible after overflow interrupt mechanism is standardized. > As this patch set goes v2, the PMU porting guide in [0] should be removed since > it contains no useful information anymore. > It seems that the document mentioned some hook functions, it is good for me to reserve this document, maybe we could try to give some modification. I would check that. Thanks > [0] Documentation/riscv/pmu.rst > [1] https://www.youtube.com/watch?v=Onvlcl4e2IU > [2] https://github.com/riscv/riscv-isa-manual/issues/402 > This proposal has been posted in Privileged Spec Task Group, in > https://lists.riscv.org/g/tech-privileged-archive/message/488?p=,,,20,0,0,0::Created,,Proposal,20,2,40,32306071 > but never receive any feedback. > [3] https://lists.riscv.org/g/tech-unixplatformspec/message/84 > I intended to discuss [2] in the Unixplatform Spec Task Group at the > online meeting, but obviously people were too busy knowing who the new > RISC-V CTO is and what he has done to even follow the agenda. > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2020-07-01 3:15 UTC|newest] Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-29 3:19 [RFC PATCH 0/6] Support raw event and DT for perf on RISC-V Zong Li 2020-06-29 3:19 ` Zong Li 2020-06-29 3:19 ` [RFC PATCH 1/6] dt-bindings: riscv: Add YAML documentation for PMU Zong Li 2020-06-29 3:19 ` Zong Li 2020-06-29 4:09 ` Anup Patel 2020-06-29 4:09 ` Anup Patel 2020-06-29 4:28 ` Zong Li 2020-06-29 4:28 ` Zong Li 2020-06-29 4:37 ` Anup Patel 2020-06-29 4:37 ` Anup Patel 2020-06-29 6:35 ` Zong Li 2020-06-29 6:35 ` Zong Li 2020-06-29 8:31 ` Anup Patel 2020-06-29 8:31 ` Anup Patel 2020-07-01 3:22 ` Zong Li 2020-07-01 3:22 ` Zong Li 2020-06-29 3:19 ` [RFC PATCH 2/6] riscv: dts: sifive: Add DT support " Zong Li 2020-06-29 3:19 ` Zong Li 2020-06-29 3:19 ` [RFC PATCH 3/6] riscv: add definition of hpmcounter CSRs Zong Li 2020-06-29 3:19 ` Zong Li 2020-06-29 3:19 ` [RFC PATCH 4/6] riscv: perf: Add raw event support Zong Li 2020-06-29 3:19 ` Zong Li 2020-06-29 4:17 ` Anup Patel 2020-06-29 4:17 ` Anup Patel 2020-06-29 4:35 ` Zong Li 2020-06-29 4:35 ` Zong Li 2020-06-29 4:40 ` Anup Patel 2020-06-29 4:40 ` Anup Patel 2020-06-29 3:19 ` [RFC PATCH 5/6] riscv: perf: introduce DT mechanism Zong Li 2020-06-29 3:19 ` Zong Li 2020-06-29 4:36 ` Anup Patel 2020-06-29 4:36 ` Anup Patel 2020-06-29 6:26 ` Zong Li 2020-06-29 6:26 ` Zong Li 2020-06-29 11:42 ` kernel test robot 2020-06-29 3:19 ` [RFC PATCH 6/6] riscv: remove PMU menu of Kconfig Zong Li 2020-06-29 3:19 ` Zong Li 2020-06-29 4:52 ` [RFC PATCH 0/6] Support raw event and DT for perf on RISC-V Anup Patel 2020-06-29 4:52 ` Anup Patel 2020-06-29 5:52 ` Zong Li 2020-06-29 5:52 ` Zong Li 2020-06-29 8:27 ` Anup Patel 2020-06-29 8:27 ` Anup Patel 2020-06-29 12:53 ` Zong Li 2020-06-29 12:53 ` Zong Li 2020-06-29 13:23 ` Anup Patel 2020-06-29 13:23 ` Anup Patel 2020-06-30 6:37 ` Zong Li 2020-06-30 6:37 ` Zong Li 2020-06-30 7:39 ` Anup Patel 2020-06-30 7:39 ` Anup Patel 2020-06-30 8:04 ` Zong Li 2020-06-30 8:04 ` Zong Li 2020-06-30 10:18 ` Anup Patel 2020-06-30 10:18 ` Anup Patel 2020-06-30 11:38 ` Anup Patel 2020-06-30 11:38 ` Anup Patel 2020-06-30 18:57 ` Atish Patra 2020-06-30 18:57 ` Atish Patra 2020-07-01 2:14 ` Zong Li 2020-07-01 2:14 ` Zong Li 2020-07-01 11:43 ` Anup Patel 2020-07-01 11:43 ` Anup Patel 2020-07-01 2:11 ` Zong Li 2020-07-01 2:11 ` Zong Li 2020-07-01 1:55 ` Zong Li 2020-07-01 1:55 ` Zong Li 2020-07-01 0:51 ` Alan Kao 2020-07-01 0:51 ` Alan Kao 2020-07-01 1:02 ` Atish Patra 2020-07-01 1:02 ` Atish Patra 2020-07-01 2:45 ` Alan Kao 2020-07-01 2:45 ` Alan Kao 2020-07-01 3:15 ` Zong Li [this message] 2020-07-01 3:15 ` Zong Li 2020-07-01 4:13 ` Anup Patel 2020-07-01 4:13 ` Anup Patel
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='CANXhq0o322Pa1kUXjBb4b21Zxrz+zXB5D7Ljyj18j_=TMKfeVg@mail.gmail.com' \ --to=zong.li@sifive.com \ --cc=alankao@andestech.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ /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: linkBe 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.