From: Mark Rutland <mark.rutland@arm.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, will.deacon@arm.com,
robin.murphy@arm.com, julien.thierry@arm.com
Subject: Re: [PATCH v3 1/7] arm_pmu: Clean up maximum period handling
Date: Tue, 19 Jun 2018 11:45:04 +0100 [thread overview]
Message-ID: <20180619104504.wpsimuuesbxwvvdr@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <1529403342-17899-2-git-send-email-suzuki.poulose@arm.com>
On Tue, Jun 19, 2018 at 11:15:36AM +0100, Suzuki K Poulose wrote:
> Each PMU defines their max_period of the counter as the maximum
> value that can be counted. Since all the PMU backends support
> 32bit counters by default, let us remove the redundant field.
>
> No functional changes.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Reviewed-by: Julien Thierry <julien.thierry@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> No changes since v2
> ---
> arch/arm/kernel/perf_event_v6.c | 2 --
> arch/arm/kernel/perf_event_v7.c | 1 -
> arch/arm/kernel/perf_event_xscale.c | 2 --
> arch/arm64/kernel/perf_event.c | 1 -
> drivers/perf/arm_pmu.c | 16 ++++++++++++----
> include/linux/perf/arm_pmu.h | 1 -
> 6 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
> index be42c4f..f64a6bf 100644
> --- a/arch/arm/kernel/perf_event_v6.c
> +++ b/arch/arm/kernel/perf_event_v6.c
> @@ -495,7 +495,6 @@ static void armv6pmu_init(struct arm_pmu *cpu_pmu)
> cpu_pmu->stop = armv6pmu_stop;
> cpu_pmu->map_event = armv6_map_event;
> cpu_pmu->num_events = 3;
> - cpu_pmu->max_period = (1LLU << 32) - 1;
> }
>
> static int armv6_1136_pmu_init(struct arm_pmu *cpu_pmu)
> @@ -546,7 +545,6 @@ static int armv6mpcore_pmu_init(struct arm_pmu *cpu_pmu)
> cpu_pmu->stop = armv6pmu_stop;
> cpu_pmu->map_event = armv6mpcore_map_event;
> cpu_pmu->num_events = 3;
> - cpu_pmu->max_period = (1LLU << 32) - 1;
>
> return 0;
> }
> diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
> index 57f01e0..ecca4cd 100644
> --- a/arch/arm/kernel/perf_event_v7.c
> +++ b/arch/arm/kernel/perf_event_v7.c
> @@ -1170,7 +1170,6 @@ static void armv7pmu_init(struct arm_pmu *cpu_pmu)
> cpu_pmu->start = armv7pmu_start;
> cpu_pmu->stop = armv7pmu_stop;
> cpu_pmu->reset = armv7pmu_reset;
> - cpu_pmu->max_period = (1LLU << 32) - 1;
> };
>
> static void armv7_read_num_pmnc_events(void *info)
> diff --git a/arch/arm/kernel/perf_event_xscale.c b/arch/arm/kernel/perf_event_xscale.c
> index 88d1a76..c4f0294 100644
> --- a/arch/arm/kernel/perf_event_xscale.c
> +++ b/arch/arm/kernel/perf_event_xscale.c
> @@ -374,7 +374,6 @@ static int xscale1pmu_init(struct arm_pmu *cpu_pmu)
> cpu_pmu->stop = xscale1pmu_stop;
> cpu_pmu->map_event = xscale_map_event;
> cpu_pmu->num_events = 3;
> - cpu_pmu->max_period = (1LLU << 32) - 1;
>
> return 0;
> }
> @@ -743,7 +742,6 @@ static int xscale2pmu_init(struct arm_pmu *cpu_pmu)
> cpu_pmu->stop = xscale2pmu_stop;
> cpu_pmu->map_event = xscale_map_event;
> cpu_pmu->num_events = 5;
> - cpu_pmu->max_period = (1LLU << 32) - 1;
>
> return 0;
> }
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 33147aa..678ecff 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -960,7 +960,6 @@ static int armv8_pmu_init(struct arm_pmu *cpu_pmu)
> cpu_pmu->start = armv8pmu_start,
> cpu_pmu->stop = armv8pmu_stop,
> cpu_pmu->reset = armv8pmu_reset,
> - cpu_pmu->max_period = (1LLU << 32) - 1,
> cpu_pmu->set_event_filter = armv8pmu_set_event_filter;
>
> return 0;
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index a6347d4..6ddc00d 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -28,6 +28,11 @@
> static DEFINE_PER_CPU(struct arm_pmu *, cpu_armpmu);
> static DEFINE_PER_CPU(int, cpu_irq);
>
> +static inline u64 arm_pmu_max_period(void)
> +{
> + return (1ULL << 32) - 1;
> +}
> +
> static int
> armpmu_map_cache_event(const unsigned (*cache_map)
> [PERF_COUNT_HW_CACHE_MAX]
> @@ -114,8 +119,10 @@ int armpmu_event_set_period(struct perf_event *event)
> struct hw_perf_event *hwc = &event->hw;
> s64 left = local64_read(&hwc->period_left);
> s64 period = hwc->sample_period;
> + u64 max_period;
> int ret = 0;
>
> + max_period = arm_pmu_max_period();
> if (unlikely(left <= -period)) {
> left = period;
> local64_set(&hwc->period_left, left);
> @@ -136,8 +143,8 @@ int armpmu_event_set_period(struct perf_event *event)
> * effect we are reducing max_period to account for
> * interrupt latency (and we are being very conservative).
> */
> - if (left > (armpmu->max_period >> 1))
> - left = armpmu->max_period >> 1;
> + if (left > (max_period >> 1))
> + left = (max_period >> 1);
>
> local64_set(&hwc->prev_count, (u64)-left);
>
> @@ -153,6 +160,7 @@ u64 armpmu_event_update(struct perf_event *event)
> struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
> struct hw_perf_event *hwc = &event->hw;
> u64 delta, prev_raw_count, new_raw_count;
> + u64 max_period = arm_pmu_max_period();
>
> again:
> prev_raw_count = local64_read(&hwc->prev_count);
> @@ -162,7 +170,7 @@ u64 armpmu_event_update(struct perf_event *event)
> new_raw_count) != prev_raw_count)
> goto again;
>
> - delta = (new_raw_count - prev_raw_count) & armpmu->max_period;
> + delta = (new_raw_count - prev_raw_count) & max_period;
>
> local64_add(delta, &event->count);
> local64_sub(delta, &hwc->period_left);
> @@ -402,7 +410,7 @@ __hw_perf_event_init(struct perf_event *event)
> * is far less likely to overtake the previous one unless
> * you have some serious IRQ latency issues.
> */
> - hwc->sample_period = armpmu->max_period >> 1;
> + hwc->sample_period = arm_pmu_max_period() >> 1;
> hwc->last_period = hwc->sample_period;
> local64_set(&hwc->period_left, hwc->sample_period);
> }
> diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
> index ad54444..12c30a2 100644
> --- a/include/linux/perf/arm_pmu.h
> +++ b/include/linux/perf/arm_pmu.h
> @@ -94,7 +94,6 @@ struct arm_pmu {
> void (*reset)(void *);
> int (*map_event)(struct perf_event *event);
> int num_events;
> - u64 max_period;
> bool secure_access; /* 32-bit ARM only */
> #define ARMV8_PMUV3_MAX_COMMON_EVENTS 0x40
> DECLARE_BITMAP(pmceid_bitmap, ARMV8_PMUV3_MAX_COMMON_EVENTS);
> --
> 2.7.4
>
next prev parent reply other threads:[~2018-06-19 10:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-19 10:15 [PATCH v3 0/7] arm64: perf: Support for chained counters Suzuki K Poulose
2018-06-19 10:15 ` [PATCH v3 1/7] arm_pmu: Clean up maximum period handling Suzuki K Poulose
2018-06-19 10:45 ` Mark Rutland [this message]
2018-06-19 10:15 ` [PATCH v3 2/7] arm_pmu: Change API to support 64bit counter values Suzuki K Poulose
2018-06-19 10:52 ` Mark Rutland
2018-06-19 10:15 ` [PATCH v3 3/7] arm_pmu: Add support for 64bit event counters Suzuki K Poulose
2018-06-19 10:57 ` Mark Rutland
2018-06-19 10:15 ` [PATCH v3 4/7] arm_pmu: Tidy up clear_event_idx call backs Suzuki K Poulose
2018-06-29 13:27 ` Mark Rutland
2018-06-29 13:40 ` Mark Rutland
2018-06-29 14:18 ` Suzuki K Poulose
2018-06-29 14:29 ` Mark Rutland
2018-06-19 10:15 ` [PATCH v3 5/7] arm64: perf: Clean up armv8pmu_select_counter Suzuki K Poulose
2018-06-29 13:29 ` Mark Rutland
2018-06-19 10:15 ` [PATCH v3 6/7] arm64: perf: Disable PMU while processing counter overflows Suzuki K Poulose
2018-06-19 10:43 ` Mark Rutland
2018-06-19 10:15 ` [PATCH v3 7/7] arm64: perf: Add support for chaining event counters Suzuki K Poulose
2018-06-29 14:01 ` Mark Rutland
2018-06-29 14:29 ` Suzuki K Poulose
2018-06-29 14:39 ` Mark Rutland
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=20180619104504.wpsimuuesbxwvvdr@lakrids.cambridge.arm.com \
--to=mark.rutland@arm.com \
--cc=julien.thierry@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=will.deacon@arm.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).