Re: [PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

2017-02-23 Thread Anurup M 



On Tuesday 21 February 2017 05:39 PM, Will Deacon wrote:

On Mon, Feb 20, 2017 at 11:09:43AM +, Mark Rutland wrote:

On Sun, Feb 19, 2017 at 01:51:03PM -0500, Anurup M wrote:

The L3 cache PMU use N-N SPI interrupt which has no support
in kernel mainline.

Could you elaborate on what you mean by this?

I don't understand what is meant here. How exactly are the interrupts
wired up in HW, and what exactly is not supported by Linux?


So use hrtimer to poll and update event
counter to avoid overflow condition for L3 cache PMU.
A interval of 10 seconds is used for the hrtimer.
The time interval can be configured in the sysfs.

I'm not too keen on giving userspace the ability to control this, since
it gives an awful lot of rope for userspace to tie around itself.

Agreed. I'd also go a step further and say that for PMUs with either
terminally broken interrupts (like this one) or just missing interrupts
(like the CPU PMU on raspberry pi iirc), then the perf core should take
care of an hrtimer in an attempt to generate samples often enough. We
already have PERF_PMU_CAP_NO_INTERRUPT, but it currently just disables
sampling events.

The fiddly part is knowing how to program the timer, and I think you'd
need the PMU driver to provide an upper-bound on events per nanosecond.
I'm pretty sure that would be highly unreliable (especially for shared
resources such as the L3), at which point, is it worth the hassle?


Agreed, it is difficult for user to arrive at a interval for the shared 
resource

like L3 cache. So I shall remove this facility exposed to user.

Shall use a realistic and safer upper bound as hrtimer interval for the 
uncore

units which do not support IRQ.

Thanks,
Anuurp


Will

Re: [PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

2017-02-23 Thread Anurup M 



On Tuesday 21 February 2017 05:39 PM, Will Deacon wrote:

On Mon, Feb 20, 2017 at 11:09:43AM +, Mark Rutland wrote:

On Sun, Feb 19, 2017 at 01:51:03PM -0500, Anurup M wrote:

The L3 cache PMU use N-N SPI interrupt which has no support
in kernel mainline.

Could you elaborate on what you mean by this?

I don't understand what is meant here. How exactly are the interrupts
wired up in HW, and what exactly is not supported by Linux?


So use hrtimer to poll and update event
counter to avoid overflow condition for L3 cache PMU.
A interval of 10 seconds is used for the hrtimer.
The time interval can be configured in the sysfs.

I'm not too keen on giving userspace the ability to control this, since
it gives an awful lot of rope for userspace to tie around itself.

Agreed. I'd also go a step further and say that for PMUs with either
terminally broken interrupts (like this one) or just missing interrupts
(like the CPU PMU on raspberry pi iirc), then the perf core should take
care of an hrtimer in an attempt to generate samples often enough. We
already have PERF_PMU_CAP_NO_INTERRUPT, but it currently just disables
sampling events.

The fiddly part is knowing how to program the timer, and I think you'd
need the PMU driver to provide an upper-bound on events per nanosecond.
I'm pretty sure that would be highly unreliable (especially for shared
resources such as the L3), at which point, is it worth the hassle?


Agreed, it is difficult for user to arrive at a interval for the shared 
resource

like L3 cache. So I shall remove this facility exposed to user.

Shall use a realistic and safer upper bound as hrtimer interval for the 
uncore

units which do not support IRQ.

Thanks,
Anuurp


Will

Re: [PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

2017-02-21 Thread Will Deacon 
On Mon, Feb 20, 2017 at 11:09:43AM +, Mark Rutland wrote:
> On Sun, Feb 19, 2017 at 01:51:03PM -0500, Anurup M wrote:
> > The L3 cache PMU use N-N SPI interrupt which has no support
> > in kernel mainline.
> 
> Could you elaborate on what you mean by this?
> 
> I don't understand what is meant here. How exactly are the interrupts
> wired up in HW, and what exactly is not supported by Linux?
> 
> > So use hrtimer to poll and update event
> > counter to avoid overflow condition for L3 cache PMU.
> > A interval of 10 seconds is used for the hrtimer.
> > The time interval can be configured in the sysfs.
> 
> I'm not too keen on giving userspace the ability to control this, since
> it gives an awful lot of rope for userspace to tie around itself.

Agreed. I'd also go a step further and say that for PMUs with either
terminally broken interrupts (like this one) or just missing interrupts
(like the CPU PMU on raspberry pi iirc), then the perf core should take
care of an hrtimer in an attempt to generate samples often enough. We
already have PERF_PMU_CAP_NO_INTERRUPT, but it currently just disables
sampling events.

The fiddly part is knowing how to program the timer, and I think you'd
need the PMU driver to provide an upper-bound on events per nanosecond.
I'm pretty sure that would be highly unreliable (especially for shared
resources such as the L3), at which point, is it worth the hassle?

Will

Re: [PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

2017-02-21 Thread Will Deacon 
On Mon, Feb 20, 2017 at 11:09:43AM +, Mark Rutland wrote:
> On Sun, Feb 19, 2017 at 01:51:03PM -0500, Anurup M wrote:
> > The L3 cache PMU use N-N SPI interrupt which has no support
> > in kernel mainline.
> 
> Could you elaborate on what you mean by this?
> 
> I don't understand what is meant here. How exactly are the interrupts
> wired up in HW, and what exactly is not supported by Linux?
> 
> > So use hrtimer to poll and update event
> > counter to avoid overflow condition for L3 cache PMU.
> > A interval of 10 seconds is used for the hrtimer.
> > The time interval can be configured in the sysfs.
> 
> I'm not too keen on giving userspace the ability to control this, since
> it gives an awful lot of rope for userspace to tie around itself.

Agreed. I'd also go a step further and say that for PMUs with either
terminally broken interrupts (like this one) or just missing interrupts
(like the CPU PMU on raspberry pi iirc), then the perf core should take
care of an hrtimer in an attempt to generate samples often enough. We
already have PERF_PMU_CAP_NO_INTERRUPT, but it currently just disables
sampling events.

The fiddly part is knowing how to program the timer, and I think you'd
need the PMU driver to provide an upper-bound on events per nanosecond.
I'm pretty sure that would be highly unreliable (especially for shared
resources such as the L3), at which point, is it worth the hassle?

Will

Re: [PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

2017-02-21 Thread Marc Zyngier 
On 21/02/17 07:07, Anurup M wrote:
> Adding Marc.
> 
> On Monday 20 February 2017 04:39 PM, Mark Rutland wrote:
>> On Sun, Feb 19, 2017 at 01:51:03PM -0500, Anurup M wrote:
>>> The L3 cache PMU use N-N SPI interrupt which has no support
>>> in kernel mainline.
>> Could you elaborate on what you mean by this?
>>
>> I don't understand what is meant here. How exactly are the interrupts
>> wired up in HW, and what exactly is not supported by Linux?
> 
> In HW the L3C overflow IRQ is wired as SPI which use N-N model.
> But according to ARM GIC V2 specification, the peripheral(hardware) 
> interrupts should use 1-N model.
> N-N model is used by SGIs. In GIC V3 spec I could not find any 
> description of N-N model.
> So I think the N-N model for SPI will not be supported.
> 
> Hi Marc,
>  Does ARM GIC support N-N module for SPI? Please share your comments.

There is no support for this kind of broadcast IRQs in any published
version of the GIC architecture. The semantics of such interrupts are
just crazy, and I'm really glad we don't support them.

What we could support is 1-of-N, but that's
(1) inefficient,
(2) impossible to virtualize correctly,
(3) only possible with GICv2.

So what you're getting is interrupts targeted at a single CPU, and
that's it.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

2017-02-21 Thread Marc Zyngier 
On 21/02/17 07:07, Anurup M wrote:
> Adding Marc.
> 
> On Monday 20 February 2017 04:39 PM, Mark Rutland wrote:
>> On Sun, Feb 19, 2017 at 01:51:03PM -0500, Anurup M wrote:
>>> The L3 cache PMU use N-N SPI interrupt which has no support
>>> in kernel mainline.
>> Could you elaborate on what you mean by this?
>>
>> I don't understand what is meant here. How exactly are the interrupts
>> wired up in HW, and what exactly is not supported by Linux?
> 
> In HW the L3C overflow IRQ is wired as SPI which use N-N model.
> But according to ARM GIC V2 specification, the peripheral(hardware) 
> interrupts should use 1-N model.
> N-N model is used by SGIs. In GIC V3 spec I could not find any 
> description of N-N model.
> So I think the N-N model for SPI will not be supported.
> 
> Hi Marc,
>  Does ARM GIC support N-N module for SPI? Please share your comments.

There is no support for this kind of broadcast IRQs in any published
version of the GIC architecture. The semantics of such interrupts are
just crazy, and I'm really glad we don't support them.

What we could support is 1-of-N, but that's
(1) inefficient,
(2) impossible to virtualize correctly,
(3) only possible with GICv2.

So what you're getting is interrupts targeted at a single CPU, and
that's it.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

2017-02-20 Thread Anurup M 

Adding Marc.

On Monday 20 February 2017 04:39 PM, Mark Rutland wrote:

On Sun, Feb 19, 2017 at 01:51:03PM -0500, Anurup M wrote:

The L3 cache PMU use N-N SPI interrupt which has no support
in kernel mainline.

Could you elaborate on what you mean by this?

I don't understand what is meant here. How exactly are the interrupts
wired up in HW, and what exactly is not supported by Linux?


In HW the L3C overflow IRQ is wired as SPI which use N-N model.
But according to ARM GIC V2 specification, the peripheral(hardware) 
interrupts should use 1-N model.
N-N model is used by SGIs. In GIC V3 spec I could not find any 
description of N-N model.

So I think the N-N model for SPI will not be supported.

Hi Marc,
Does ARM GIC support N-N module for SPI? Please share your comments.


So use hrtimer to poll and update event
counter to avoid overflow condition for L3 cache PMU.
A interval of 10 seconds is used for the hrtimer.
The time interval can be configured in the sysfs.

I'm not too keen on giving userspace the ability to control this, since
it gives an awful lot of rope for userspace to tie around itself.


I thought of giving facility to system user to decide the interval based 
on the system usage.


If we do not provide this facility, then we always set the worst case 
overflow interval?

I am trying to understand it better.

Thanks,
Anurup


Thanks,
Mark.

Re: [PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

2017-02-20 Thread Anurup M 

Adding Marc.

On Monday 20 February 2017 04:39 PM, Mark Rutland wrote:

On Sun, Feb 19, 2017 at 01:51:03PM -0500, Anurup M wrote:

The L3 cache PMU use N-N SPI interrupt which has no support
in kernel mainline.

Could you elaborate on what you mean by this?

I don't understand what is meant here. How exactly are the interrupts
wired up in HW, and what exactly is not supported by Linux?


In HW the L3C overflow IRQ is wired as SPI which use N-N model.
But according to ARM GIC V2 specification, the peripheral(hardware) 
interrupts should use 1-N model.
N-N model is used by SGIs. In GIC V3 spec I could not find any 
description of N-N model.

So I think the N-N model for SPI will not be supported.

Hi Marc,
Does ARM GIC support N-N module for SPI? Please share your comments.


So use hrtimer to poll and update event
counter to avoid overflow condition for L3 cache PMU.
A interval of 10 seconds is used for the hrtimer.
The time interval can be configured in the sysfs.

I'm not too keen on giving userspace the ability to control this, since
it gives an awful lot of rope for userspace to tie around itself.


I thought of giving facility to system user to decide the interval based 
on the system usage.


If we do not provide this facility, then we always set the worst case 
overflow interval?

I am trying to understand it better.

Thanks,
Anurup


Thanks,
Mark.

Re: [PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

2017-02-20 Thread Mark Rutland 
On Sun, Feb 19, 2017 at 01:51:03PM -0500, Anurup M wrote:
> The L3 cache PMU use N-N SPI interrupt which has no support
> in kernel mainline.

Could you elaborate on what you mean by this?

I don't understand what is meant here. How exactly are the interrupts
wired up in HW, and what exactly is not supported by Linux?

> So use hrtimer to poll and update event
> counter to avoid overflow condition for L3 cache PMU.
> A interval of 10 seconds is used for the hrtimer.
> The time interval can be configured in the sysfs.

I'm not too keen on giving userspace the ability to control this, since
it gives an awful lot of rope for userspace to tie around itself.

Thanks,
Mark.

Re: [PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

2017-02-20 Thread Mark Rutland 
On Sun, Feb 19, 2017 at 01:51:03PM -0500, Anurup M wrote:
> The L3 cache PMU use N-N SPI interrupt which has no support
> in kernel mainline.

Could you elaborate on what you mean by this?

I don't understand what is meant here. How exactly are the interrupts
wired up in HW, and what exactly is not supported by Linux?

> So use hrtimer to poll and update event
> counter to avoid overflow condition for L3 cache PMU.
> A interval of 10 seconds is used for the hrtimer.
> The time interval can be configured in the sysfs.

I'm not too keen on giving userspace the ability to control this, since
it gives an awful lot of rope for userspace to tie around itself.

Thanks,
Mark.

[PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

2017-02-19 Thread Anurup M 
The L3 cache PMU use N-N SPI interrupt which has no support
in kernel mainline. So use hrtimer to poll and update event
counter to avoid overflow condition for L3 cache PMU.
A interval of 10 seconds is used for the hrtimer.
The time interval can be configured in the sysfs.

Signed-off-by: Dikshit N 
Signed-off-by: Anurup M 
---
 drivers/perf/hisilicon/hisi_uncore_l3c.c | 44 +++
 drivers/perf/hisilicon/hisi_uncore_pmu.c | 95 
 drivers/perf/hisilicon/hisi_uncore_pmu.h | 17 ++
 3 files changed, 156 insertions(+)

diff --git a/drivers/perf/hisilicon/hisi_uncore_l3c.c 
b/drivers/perf/hisilicon/hisi_uncore_l3c.c
index 5c6bea0..d211020 100644
--- a/drivers/perf/hisilicon/hisi_uncore_l3c.c
+++ b/drivers/perf/hisilicon/hisi_uncore_l3c.c
@@ -20,6 +20,8 @@
  * along with this program.  If not, see .
  */
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -53,6 +55,22 @@ enum armv8_hisi_l3c_counters {
 #define L3C_CNT0_REG_OFF 0x170
 #define L3C_EVENT_EN 0x100
 
+/*
+ * Default timer frequency to poll and avoid counter overflow.
+ * CPU speed = 2.4Ghz, Therefore Access time = 0.4ns
+ * L1 cache - 2 way set associative
+ * L2  - 16 way set associative
+ * L3  - 16 way set associative. L3 cache has 4 banks.
+ *
+ * Overflow time = 2^31 * (acces time L1 + access time L2 + access time L3)
+ * = 2^31 * ((2 * 0.4ns) + (16 * 0.4ns) + (4 * 16 * 0.4ns)) = 70 seconds
+ *
+ * L3 cache is also used by devices like PCIe, SAS etc. at
+ * the same time. So the overflow time could be even smaller.
+ * So on a safe side we use a timer interval of 10sec
+ */
+#define L3C_HRTIMER_INTERVAL (10LL * MSEC_PER_SEC)
+
 #define GET_MODULE_ID(hwmod_data) hwmod_data->l3c_hwcfg.module_id
 #define GET_BANK_SEL(hwmod_data) hwmod_data->l3c_hwcfg.bank_select
 
@@ -467,6 +485,18 @@ static const struct attribute_group hisi_l3c_attr_group = {
 
 static DEVICE_ATTR(cpumask, 0444, hisi_cpumask_sysfs_show, NULL);
 
+static DEVICE_ATTR(hrtimer_interval, 0644, hisi_hrtimer_interval_sysfs_show,
+   hisi_hrtimer_interval_sysfs_store);
+
+static struct attribute *hisi_l3c_hrtimer_interval_attrs[] = {
+   _attr_hrtimer_interval.attr,
+   NULL,
+};
+
+static const struct attribute_group hisi_l3c_hrtimer_interval_attr_group = {
+   .attrs = hisi_l3c_hrtimer_interval_attrs,
+};
+
 static struct attribute *hisi_l3c_cpumask_attrs[] = {
_attr_cpumask.attr,
NULL,
@@ -481,6 +511,7 @@ static const struct attribute_group 
*hisi_l3c_pmu_attr_groups[] = {
_l3c_format_group,
_l3c_events_group,
_l3c_cpumask_attr_group,
+   _l3c_hrtimer_interval_attr_group,
NULL,
 };
 
@@ -496,6 +527,15 @@ static struct hisi_uncore_ops hisi_uncore_l3c_ops = {
.write_counter = hisi_l3c_write_counter,
 };
 
+/* Initialize hrtimer to poll for avoiding counter overflow */
+static void hisi_l3c_hrtimer_init(struct hisi_pmu *l3c_pmu)
+{
+   INIT_LIST_HEAD(_pmu->active_list);
+   l3c_pmu->ops->start_hrtimer = hisi_hrtimer_start;
+   l3c_pmu->ops->stop_hrtimer = hisi_hrtimer_stop;
+   hisi_hrtimer_init(l3c_pmu, L3C_HRTIMER_INTERVAL);
+}
+
 static int hisi_l3c_pmu_init(struct hisi_pmu *l3c_pmu,
struct hisi_djtag_client *client)
 {
@@ -505,6 +545,7 @@ static int hisi_l3c_pmu_init(struct hisi_pmu *l3c_pmu,
 
l3c_pmu->num_events = HISI_HWEVENT_L3C_EVENT_MAX;
l3c_pmu->num_counters = HISI_IDX_L3C_COUNTER_MAX;
+   l3c_pmu->num_active = 0;
l3c_pmu->scl_id = hisi_djtag_get_sclid(client);
 
l3c_pmu->name = kasprintf(GFP_KERNEL, "hisi_l3c%u_%u",
@@ -515,6 +556,9 @@ static int hisi_l3c_pmu_init(struct hisi_pmu *l3c_pmu,
/* Pick one core to use for cpumask attributes */
cpumask_set_cpu(smp_processor_id(), _pmu->cpu);
 
+   /* Use hrtimer to poll for avoiding counter overflow */
+   hisi_l3c_hrtimer_init(l3c_pmu);
+
return 0;
 }
 
diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.c 
b/drivers/perf/hisilicon/hisi_uncore_pmu.c
index 200e673e..377e1bc 100644
--- a/drivers/perf/hisilicon/hisi_uncore_pmu.c
+++ b/drivers/perf/hisilicon/hisi_uncore_pmu.c
@@ -66,6 +66,83 @@ ssize_t hisi_cpumask_sysfs_show(struct device *dev,
return cpumap_print_to_pagebuf(true, buf, _pmu->cpu);
 }
 
+/*
+ * sysfs hrtimer_interval attributes
+ */
+ssize_t hisi_hrtimer_interval_sysfs_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+   struct pmu *pmu = dev_get_drvdata(dev);
+   struct hisi_pmu *hisi_pmu = to_hisi_pmu(pmu);
+
+   if (hisi_pmu->hrt_duration)
+   return sprintf(buf, "%llu\n",
+  hisi_pmu->hrt_duration);
+   return 0;
+}
+
+ssize_t hisi_hrtimer_interval_sysfs_store(struct device *dev,
+

[PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

2017-02-19 Thread Anurup M 
The L3 cache PMU use N-N SPI interrupt which has no support
in kernel mainline. So use hrtimer to poll and update event
counter to avoid overflow condition for L3 cache PMU.
A interval of 10 seconds is used for the hrtimer.
The time interval can be configured in the sysfs.

Signed-off-by: Dikshit N 
Signed-off-by: Anurup M 
---
 drivers/perf/hisilicon/hisi_uncore_l3c.c | 44 +++
 drivers/perf/hisilicon/hisi_uncore_pmu.c | 95 
 drivers/perf/hisilicon/hisi_uncore_pmu.h | 17 ++
 3 files changed, 156 insertions(+)

diff --git a/drivers/perf/hisilicon/hisi_uncore_l3c.c 
b/drivers/perf/hisilicon/hisi_uncore_l3c.c
index 5c6bea0..d211020 100644
--- a/drivers/perf/hisilicon/hisi_uncore_l3c.c
+++ b/drivers/perf/hisilicon/hisi_uncore_l3c.c
@@ -20,6 +20,8 @@
  * along with this program.  If not, see .
  */
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -53,6 +55,22 @@ enum armv8_hisi_l3c_counters {
 #define L3C_CNT0_REG_OFF 0x170
 #define L3C_EVENT_EN 0x100
 
+/*
+ * Default timer frequency to poll and avoid counter overflow.
+ * CPU speed = 2.4Ghz, Therefore Access time = 0.4ns
+ * L1 cache - 2 way set associative
+ * L2  - 16 way set associative
+ * L3  - 16 way set associative. L3 cache has 4 banks.
+ *
+ * Overflow time = 2^31 * (acces time L1 + access time L2 + access time L3)
+ * = 2^31 * ((2 * 0.4ns) + (16 * 0.4ns) + (4 * 16 * 0.4ns)) = 70 seconds
+ *
+ * L3 cache is also used by devices like PCIe, SAS etc. at
+ * the same time. So the overflow time could be even smaller.
+ * So on a safe side we use a timer interval of 10sec
+ */
+#define L3C_HRTIMER_INTERVAL (10LL * MSEC_PER_SEC)
+
 #define GET_MODULE_ID(hwmod_data) hwmod_data->l3c_hwcfg.module_id
 #define GET_BANK_SEL(hwmod_data) hwmod_data->l3c_hwcfg.bank_select
 
@@ -467,6 +485,18 @@ static const struct attribute_group hisi_l3c_attr_group = {
 
 static DEVICE_ATTR(cpumask, 0444, hisi_cpumask_sysfs_show, NULL);
 
+static DEVICE_ATTR(hrtimer_interval, 0644, hisi_hrtimer_interval_sysfs_show,
+   hisi_hrtimer_interval_sysfs_store);
+
+static struct attribute *hisi_l3c_hrtimer_interval_attrs[] = {
+   _attr_hrtimer_interval.attr,
+   NULL,
+};
+
+static const struct attribute_group hisi_l3c_hrtimer_interval_attr_group = {
+   .attrs = hisi_l3c_hrtimer_interval_attrs,
+};
+
 static struct attribute *hisi_l3c_cpumask_attrs[] = {
_attr_cpumask.attr,
NULL,
@@ -481,6 +511,7 @@ static const struct attribute_group 
*hisi_l3c_pmu_attr_groups[] = {
_l3c_format_group,
_l3c_events_group,
_l3c_cpumask_attr_group,
+   _l3c_hrtimer_interval_attr_group,
NULL,
 };
 
@@ -496,6 +527,15 @@ static struct hisi_uncore_ops hisi_uncore_l3c_ops = {
.write_counter = hisi_l3c_write_counter,
 };
 
+/* Initialize hrtimer to poll for avoiding counter overflow */
+static void hisi_l3c_hrtimer_init(struct hisi_pmu *l3c_pmu)
+{
+   INIT_LIST_HEAD(_pmu->active_list);
+   l3c_pmu->ops->start_hrtimer = hisi_hrtimer_start;
+   l3c_pmu->ops->stop_hrtimer = hisi_hrtimer_stop;
+   hisi_hrtimer_init(l3c_pmu, L3C_HRTIMER_INTERVAL);
+}
+
 static int hisi_l3c_pmu_init(struct hisi_pmu *l3c_pmu,
struct hisi_djtag_client *client)
 {
@@ -505,6 +545,7 @@ static int hisi_l3c_pmu_init(struct hisi_pmu *l3c_pmu,
 
l3c_pmu->num_events = HISI_HWEVENT_L3C_EVENT_MAX;
l3c_pmu->num_counters = HISI_IDX_L3C_COUNTER_MAX;
+   l3c_pmu->num_active = 0;
l3c_pmu->scl_id = hisi_djtag_get_sclid(client);
 
l3c_pmu->name = kasprintf(GFP_KERNEL, "hisi_l3c%u_%u",
@@ -515,6 +556,9 @@ static int hisi_l3c_pmu_init(struct hisi_pmu *l3c_pmu,
/* Pick one core to use for cpumask attributes */
cpumask_set_cpu(smp_processor_id(), _pmu->cpu);
 
+   /* Use hrtimer to poll for avoiding counter overflow */
+   hisi_l3c_hrtimer_init(l3c_pmu);
+
return 0;
 }
 
diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.c 
b/drivers/perf/hisilicon/hisi_uncore_pmu.c
index 200e673e..377e1bc 100644
--- a/drivers/perf/hisilicon/hisi_uncore_pmu.c
+++ b/drivers/perf/hisilicon/hisi_uncore_pmu.c
@@ -66,6 +66,83 @@ ssize_t hisi_cpumask_sysfs_show(struct device *dev,
return cpumap_print_to_pagebuf(true, buf, _pmu->cpu);
 }
 
+/*
+ * sysfs hrtimer_interval attributes
+ */
+ssize_t hisi_hrtimer_interval_sysfs_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+   struct pmu *pmu = dev_get_drvdata(dev);
+   struct hisi_pmu *hisi_pmu = to_hisi_pmu(pmu);
+
+   if (hisi_pmu->hrt_duration)
+   return sprintf(buf, "%llu\n",
+  hisi_pmu->hrt_duration);
+   return 0;
+}
+
+ssize_t hisi_hrtimer_interval_sysfs_store(struct device *dev,
+ struct