From: Ming Lei <ming.lei@canonical.com> To: Will Deacon <will.deacon@arm.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>, "eranian@gmail.com" <eranian@gmail.com>, "Shilimkar, Santosh" <santosh.shilimkar@ti.com>, David Long <dave.long@linaro.org>, "b-cousson@ti.com" <b-cousson@ti.com>, "mans@mansr.com" <mans@mansr.com>, linux-arm <linux-arm-kernel@lists.infradead.org>, Ingo Molnar <mingo@elte.hu>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: oprofile and ARM A9 hardware counter Date: Fri, 17 Feb 2012 00:12:49 +0800 [thread overview] Message-ID: <CACVXFVM472hz+na7o2wJr1CPq-W=YB7i0UwtrsUf62+ryzWp8A@mail.gmail.com> (raw) In-Reply-To: <20120216150004.GE2641@mudshark.cambridge.arm.com> On Thu, Feb 16, 2012 at 11:00 PM, Will Deacon <will.deacon@arm.com> wrote: > On Thu, Feb 16, 2012 at 10:25:05AM +0000, Ming Lei wrote: >> On Thu, Feb 16, 2012 at 12:38 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: >> > >> > So what this patch seems to do is put that filter on period in >> > perf_ctx_adjust_freq(). Not making sense.. nor can I see a HZ >> > dependency, perf_ctx_adjust_freq() uses TICK_NSEC as time base. >> >> Yes, you are right, I remembered it was observed it on -rc1, and >> Stephane's unthrottling >> patch was not merged at that time. Today I investigated the problem >> further on -rc3 and found that seems the problem is caused by arm pmu code. > > As I reported previously, Stephane's patch is causing warnings on -rc3: > > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/084391.html > > so I'd like to get to the bottom of that before changing anything else. Looks I am luck enough and not see the warning on OMAP4, either -rc3 or -rc3--next-20120210, :-) Maybe we have different config options. > > I'd also like to know why this has only been reported on OMAP4 and I can't > reproduce it on my boards. > >> The patch below may fix the problem, now about 40000 sample events >> can be generated on the command: >> >> 'perf record -e cycles -F 4000 ./noploop 10&& perf report -D | tail -20' >> >> armpmu_event_update may be called in tick path, so the running counter >> will be overflowed and produce a great value of 'delta', then a mistaken >> count is stored into event->count and event->hw.freq_count_stamp. Finally >> the two variables are not synchronous, then a invalid and large period is >> computed and written to pmu, and sample events are decreased much. > > Hmm, so are you observing an event overflow during the tick handler? This Yes, I am sure I can observe it without much difficulty. > should be fine unless the new value has wrapped past the previous one (i.e. > more than 2^32 events have occurred). I find this extremely unlikely for > sample-based profiling unless you have some major IRQ latency issues... IMO, it is not so difficult to get it, suppose prev_raw_count is 1000000 and -prev_raw_count was write to one pmu counter, then the counter will be expired and pmu irq is not handled quickly enough, so the pmu counter will warp and start counting from zero. When the tick is scheduled just before handling pmu irq, armpmu_event_update() is called to read the pmu counter as 'new_raw_count', suppose it is 100, then the issue is triggered: u64 delta = 100 - 1000000 = 18446744073708551716. Looks the higher the frequency is, the easier the problem is reproduced. > > The only way I can think of improving this (bearing in mind that at some > point we're limited by 32 bits of counter) is to check for overflow in the > tick path and then invoke the PMU irq handler if there is an overflow, but > that's really not very nice. Also we may remove the 'overflow' parameter from armpmu_event_update, and introduce armpmu->is_overflow(idx) callback to check if the counter(event) is overflow inside armpmu_event_update. IMO, the pmu irq can't be lost, so the pmu irq handler is not needed to invoke in tick path. > >> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c >> index 5bb91bf..789700a 100644 >> --- a/arch/arm/kernel/perf_event.c >> +++ b/arch/arm/kernel/perf_event.c >> @@ -193,13 +193,8 @@ again: >> new_raw_count) != prev_raw_count) >> goto again; >> >> - new_raw_count &= armpmu->max_period; >> - prev_raw_count &= armpmu->max_period; >> - >> - if (overflow) >> - delta = armpmu->max_period - prev_raw_count + new_raw_count + 1; >> - else >> - delta = new_raw_count - prev_raw_count; >> + delta = (armpmu->max_period - prev_raw_count + new_raw_count >> + + 1) & armpmu->max_period; > > This breaks when more than max_period events have passed. See a737823d > ("ARM: 6835/1: perf: ensure overflows aren't missed due to IRQ latency"). Sorry, I didn't notice the commit and the problem addressed, so looks the 'overflow' information is needed for armpmu_event_update. thanks, -- Ming Lei
WARNING: multiple messages have this Message-ID (diff)
From: ming.lei@canonical.com (Ming Lei) To: linux-arm-kernel@lists.infradead.org Subject: oprofile and ARM A9 hardware counter Date: Fri, 17 Feb 2012 00:12:49 +0800 [thread overview] Message-ID: <CACVXFVM472hz+na7o2wJr1CPq-W=YB7i0UwtrsUf62+ryzWp8A@mail.gmail.com> (raw) In-Reply-To: <20120216150004.GE2641@mudshark.cambridge.arm.com> On Thu, Feb 16, 2012 at 11:00 PM, Will Deacon <will.deacon@arm.com> wrote: > On Thu, Feb 16, 2012 at 10:25:05AM +0000, Ming Lei wrote: >> On Thu, Feb 16, 2012 at 12:38 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: >> > >> > So what this patch seems to do is put that filter on period in >> > perf_ctx_adjust_freq(). Not making sense.. nor can I see a HZ >> > dependency, perf_ctx_adjust_freq() uses TICK_NSEC as time base. >> >> Yes, you are right, I remembered it was observed it on -rc1, and >> Stephane's unthrottling >> patch was not merged at that time. Today I investigated the problem >> further on -rc3 and found that seems the problem is caused by arm pmu code. > > As I reported previously, Stephane's patch is causing warnings on -rc3: > > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/084391.html > > so I'd like to get to the bottom of that before changing anything else. Looks I am luck enough and not see the warning on OMAP4, either -rc3 or -rc3--next-20120210, :-) Maybe we have different config options. > > I'd also like to know why this has only been reported on OMAP4 and I can't > reproduce it on my boards. > >> The patch below may fix the problem, now about 40000 sample events >> can be generated on the command: >> >> ? ? ? 'perf record -e cycles -F 4000 ?./noploop 10&& perf report -D | tail -20' >> >> armpmu_event_update may be called in tick path, so the running counter >> will be overflowed and produce a great value of 'delta', then a mistaken >> count is stored into event->count and event->hw.freq_count_stamp. Finally >> the two variables are not synchronous, then a invalid and large period is >> computed and written to pmu, and sample events are decreased much. > > Hmm, so are you observing an event overflow during the tick handler? This Yes, I am sure I can observe it without much difficulty. > should be fine unless the new value has wrapped past the previous one (i.e. > more than 2^32 events have occurred). I find this extremely unlikely for > sample-based profiling unless you have some major IRQ latency issues... IMO, it is not so difficult to get it, suppose prev_raw_count is 1000000 and -prev_raw_count was write to one pmu counter, then the counter will be expired and pmu irq is not handled quickly enough, so the pmu counter will warp and start counting from zero. When the tick is scheduled just before handling pmu irq, armpmu_event_update() is called to read the pmu counter as 'new_raw_count', suppose it is 100, then the issue is triggered: u64 delta = 100 - 1000000 = 18446744073708551716. Looks the higher the frequency is, the easier the problem is reproduced. > > The only way I can think of improving this (bearing in mind that at some > point we're limited by 32 bits of counter) is to check for overflow in the > tick path and then invoke the PMU irq handler if there is an overflow, but > that's really not very nice. Also we may remove the 'overflow' parameter from armpmu_event_update, and introduce armpmu->is_overflow(idx) callback to check if the counter(event) is overflow inside armpmu_event_update. IMO, the pmu irq can't be lost, so the pmu irq handler is not needed to invoke in tick path. > >> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c >> index 5bb91bf..789700a 100644 >> --- a/arch/arm/kernel/perf_event.c >> +++ b/arch/arm/kernel/perf_event.c >> @@ -193,13 +193,8 @@ again: >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?new_raw_count) != prev_raw_count) >> ? ? ? ? ? ? ? goto again; >> >> - ? ? new_raw_count &= armpmu->max_period; >> - ? ? prev_raw_count &= armpmu->max_period; >> - >> - ? ? if (overflow) >> - ? ? ? ? ? ? delta = armpmu->max_period - prev_raw_count + new_raw_count + 1; >> - ? ? else >> - ? ? ? ? ? ? delta = new_raw_count - prev_raw_count; >> + ? ? delta = (armpmu->max_period - prev_raw_count + new_raw_count >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? + 1) & armpmu->max_period; > > This breaks when more than max_period events have passed. See a737823d > ("ARM: 6835/1: perf: ensure overflows aren't missed due to IRQ latency"). Sorry, I didn't notice the commit and the problem addressed, so looks the 'overflow' information is needed for armpmu_event_update. thanks, -- Ming Lei
next prev parent reply other threads:[~2012-02-16 16:12 UTC|newest] Thread overview: 257+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <1328578047.1724.17.camel@dave-Dell-System-XPS-L502X> [not found] ` <CAMQu2gwfo5JXAqQaLUNs7C7J3TUhEO2zOcyD0Rk-D_O61Yrfag@mail.gmail.com> [not found] ` <CAMsRxfLNBbQO5XF+EHJqNsnW+s=ay3mjSV5dh=sxdwzktUu03g@mail.gmail.com> [not found] ` <CAMQu2gzfNAwtf1c6jrTZpfGMSqBgBrQKmFTeCFzbvMh9ESBDUg@mail.gmail.com> [not found] ` <CAMsRxfKR1ODH56BtcUT5Dv6qOVEYGVheEcW9ugXsZmLKok==bg@mail.gmail.com> 2012-02-07 10:53 ` oprofile and ARM A9 hardware counter Shilimkar, Santosh 2012-02-07 11:09 ` Shilimkar, Santosh 2012-02-07 11:25 ` stephane eranian 2012-02-07 11:39 ` Shilimkar, Santosh 2012-02-07 11:59 ` stephane eranian 2012-02-07 15:30 ` Will Deacon 2012-02-08 2:24 ` Ming Lei 2012-02-08 2:24 ` Ming Lei 2012-02-15 16:38 ` Peter Zijlstra 2012-02-15 16:38 ` Peter Zijlstra 2012-02-16 10:25 ` Ming Lei 2012-02-16 10:25 ` Ming Lei 2012-02-16 15:00 ` Will Deacon 2012-02-16 15:00 ` Will Deacon 2012-02-16 16:12 ` Ming Lei [this message] 2012-02-16 16:12 ` Ming Lei 2012-02-16 16:19 ` Peter Zijlstra 2012-02-16 16:19 ` Peter Zijlstra 2012-02-16 16:37 ` Ming Lei 2012-02-16 16:37 ` Ming Lei 2012-02-16 18:08 ` Will Deacon 2012-02-16 18:08 ` Will Deacon 2012-02-17 5:24 ` Ming Lei 2012-02-17 5:24 ` Ming Lei 2012-02-17 10:26 ` Will Deacon 2012-02-17 10:26 ` Will Deacon 2012-02-20 3:19 ` Ming Lei 2012-02-20 3:19 ` Ming Lei 2012-02-20 9:44 ` Will Deacon 2012-02-20 9:44 ` Will Deacon 2012-02-13 13:15 ` Will Deacon [not found] ` <1329508513.1858.15.camel@dave-Dell-System-XPS-L502X> 2012-02-18 4:31 ` Shilimkar, Santosh 2012-04-03 9:44 ` Will Deacon 2012-04-03 9:47 ` Shilimkar, Santosh [not found] ` <CACVXFVN0E_deS2d50mfufO5QZSwh=34BppCL++oxtc3nfN_ugA@mail.gmail.com> [not found] ` <1328664644.1678.15.camel@dave-Dell-System-XPS-L502X> 2012-02-09 20:05 ` David A. Long [not found] <CAAO=S0+L2Q1YZC-pfm2Lz8jPooTeHYOMaZbtRgHYFoL_m7rvhA@mail.gmail.com> [not found] ` <4F0B182D.7060507@us.ibm.com> 2012-01-09 22:49 ` Will Deacon 2012-01-09 22:49 ` Will Deacon 2012-01-09 23:30 ` Ming Lei 2012-01-09 23:30 ` Ming Lei 2012-01-10 0:46 ` stephane eranian 2012-01-10 0:46 ` stephane eranian 2012-01-18 4:18 ` Ming Lei 2012-01-18 4:18 ` Ming Lei 2012-01-18 9:33 ` Ming Lei 2012-01-18 9:33 ` Ming Lei 2012-01-18 11:39 ` Shilimkar, Santosh 2012-01-18 11:39 ` Shilimkar, Santosh 2012-01-18 12:24 ` Ming Lei 2012-01-18 12:24 ` Ming Lei 2012-01-18 12:33 ` Shilimkar, Santosh 2012-01-18 12:33 ` Shilimkar, Santosh 2012-04-03 9:25 ` Will Deacon 2012-04-03 9:25 ` Will Deacon 2012-04-03 9:42 ` Shilimkar, Santosh 2012-04-03 9:42 ` Shilimkar, Santosh 2012-04-03 9:47 ` Will Deacon 2012-04-03 9:47 ` Will Deacon 2012-04-03 10:01 ` Shilimkar, Santosh 2012-04-03 10:01 ` Shilimkar, Santosh 2012-04-03 12:34 ` Will Deacon 2012-04-03 12:34 ` Will Deacon 2012-04-03 12:41 ` Shilimkar, Santosh 2012-04-03 12:41 ` Shilimkar, Santosh 2012-04-03 14:27 ` Kevin Hilman 2012-04-03 14:27 ` Kevin Hilman 2012-04-03 16:07 ` Will Deacon 2012-04-03 16:07 ` Will Deacon 2012-04-03 23:14 ` Kevin Hilman 2012-04-03 23:14 ` Kevin Hilman 2012-04-03 23:29 ` Paul Walmsley 2012-04-03 23:29 ` Paul Walmsley 2012-04-04 3:42 ` Ming Lei 2012-04-04 3:42 ` Ming Lei 2012-04-04 11:15 ` Will Deacon 2012-04-04 11:15 ` Will Deacon 2012-04-26 18:07 ` Will Deacon 2012-04-26 18:07 ` Will Deacon 2012-04-30 22:25 ` Kevin Hilman 2012-04-30 22:25 ` Kevin Hilman 2012-05-07 17:27 ` Ming Lei 2012-05-07 17:27 ` Ming Lei 2012-05-04 22:17 ` Jon Hunter 2012-05-04 22:17 ` Jon Hunter 2012-05-07 17:15 ` Kevin Hilman 2012-05-07 17:15 ` Kevin Hilman 2012-05-07 19:53 ` Jon Hunter 2012-05-07 19:53 ` Jon Hunter 2012-05-07 23:28 ` Kevin Hilman 2012-05-07 23:28 ` Kevin Hilman 2012-05-08 11:01 ` Cousson, Benoit 2012-05-08 11:01 ` Cousson, Benoit 2012-05-08 11:23 ` Jean Pihet 2012-05-08 11:23 ` Jean Pihet 2012-05-08 12:37 ` Cousson, Benoit 2012-05-08 12:37 ` Cousson, Benoit 2012-05-08 13:18 ` Jean Pihet 2012-05-08 13:18 ` Jean Pihet 2012-05-08 14:00 ` Kevin Hilman 2012-05-08 14:00 ` Kevin Hilman 2012-05-08 14:03 ` Cousson, Benoit 2012-05-08 14:03 ` Cousson, Benoit 2012-05-08 16:18 ` Kevin Hilman 2012-05-08 16:18 ` Kevin Hilman 2012-05-08 19:51 ` Jon Hunter 2012-05-08 19:51 ` Jon Hunter 2012-05-08 21:28 ` Kevin Hilman 2012-05-08 21:28 ` Kevin Hilman 2012-05-08 22:20 ` Jon Hunter 2012-05-08 22:20 ` Jon Hunter 2012-05-08 22:12 ` Ming Lei 2012-05-08 22:12 ` Ming Lei 2012-05-08 17:31 ` Jon Hunter 2012-05-08 17:31 ` Jon Hunter 2012-05-08 21:22 ` Kevin Hilman 2012-05-08 21:22 ` Kevin Hilman 2012-05-08 23:59 ` Jon Hunter 2012-05-08 23:59 ` Jon Hunter 2012-05-09 10:58 ` Cousson, Benoit 2012-05-09 10:58 ` Cousson, Benoit 2012-05-09 18:04 ` Jon Hunter 2012-05-09 18:04 ` Jon Hunter 2012-05-09 19:28 ` Jon Hunter 2012-05-09 19:28 ` Jon Hunter 2012-05-09 21:45 ` Jon Hunter 2012-05-09 21:45 ` Jon Hunter 2012-05-10 8:44 ` Will Deacon 2012-05-10 8:44 ` Will Deacon 2012-05-10 9:12 ` stephane eranian 2012-05-10 9:12 ` stephane eranian 2012-05-10 18:55 ` Jon Hunter 2012-05-10 18:55 ` Jon Hunter 2012-05-11 12:25 ` Will Deacon 2012-05-11 12:25 ` Will Deacon 2012-05-11 13:47 ` Jon Hunter 2012-05-11 13:47 ` Jon Hunter 2012-05-11 13:49 ` Will Deacon 2012-05-11 13:49 ` Will Deacon 2012-05-11 14:52 ` Jon Hunter 2012-05-11 14:52 ` Jon Hunter 2012-05-11 15:02 ` Will Deacon 2012-05-11 15:02 ` Will Deacon 2012-05-11 16:31 ` Jon Hunter 2012-05-11 16:31 ` Jon Hunter 2012-05-11 16:38 ` Will Deacon 2012-05-11 16:38 ` Will Deacon 2012-05-11 23:51 ` Jon Hunter 2012-05-11 23:51 ` Jon Hunter 2012-05-15 13:52 ` Will Deacon 2012-05-15 13:52 ` Will Deacon 2012-05-10 14:12 ` Kevin Hilman 2012-05-10 14:12 ` Kevin Hilman 2012-05-10 19:05 ` Jon Hunter 2012-05-10 19:05 ` Jon Hunter 2012-05-10 6:59 ` Santosh Shilimkar 2012-05-10 6:59 ` Santosh Shilimkar 2012-05-08 21:50 ` Paul Walmsley 2012-05-08 21:50 ` Paul Walmsley 2012-04-04 0:00 ` Paul Walmsley 2012-04-04 0:00 ` Paul Walmsley 2012-04-04 11:07 ` Will Deacon 2012-04-04 11:07 ` Will Deacon 2012-01-18 9:54 ` stephane eranian 2012-01-18 9:54 ` stephane eranian 2012-01-18 10:07 ` Ming Lei 2012-01-18 10:07 ` Ming Lei 2012-01-18 21:58 ` stephane eranian 2012-01-18 21:58 ` stephane eranian 2012-01-19 1:21 ` Ming Lei 2012-01-19 1:21 ` Ming Lei 2012-01-19 11:34 ` stephane eranian 2012-01-19 11:34 ` stephane eranian 2012-01-19 12:45 ` Ming Lei 2012-01-19 12:45 ` Ming Lei 2012-01-19 12:51 ` stephane eranian 2012-01-19 12:51 ` stephane eranian 2012-01-19 12:55 ` stephane eranian 2012-01-19 12:55 ` stephane eranian 2012-01-19 13:14 ` Ming Lei 2012-01-19 13:14 ` Ming Lei 2012-01-19 13:26 ` Ming Lei 2012-01-19 13:26 ` Ming Lei 2012-01-19 13:32 ` stephane eranian 2012-01-19 13:32 ` stephane eranian 2012-01-19 13:51 ` Ming Lei 2012-01-19 13:51 ` Ming Lei 2012-01-19 17:07 ` stephane eranian 2012-01-19 17:07 ` stephane eranian 2012-01-20 13:47 ` stephane eranian 2012-01-20 13:47 ` stephane eranian 2012-01-21 3:25 ` Ming Lei 2012-01-21 3:25 ` Ming Lei 2012-01-21 9:16 ` stephane eranian 2012-01-21 9:16 ` stephane eranian 2012-01-27 12:13 ` Will Deacon 2012-01-27 12:13 ` Will Deacon 2012-01-27 12:45 ` stephane eranian 2012-01-27 12:45 ` stephane eranian 2012-01-27 12:56 ` Måns Rullgård 2012-01-27 12:56 ` Måns Rullgård 2012-01-27 13:28 ` Will Deacon 2012-01-27 13:28 ` Will Deacon 2012-01-27 13:32 ` stephane eranian 2012-01-27 13:32 ` stephane eranian 2012-01-27 13:47 ` Måns Rullgård 2012-01-27 13:47 ` Måns Rullgård 2012-01-27 13:56 ` Will Deacon 2012-01-27 13:56 ` Will Deacon 2012-01-27 14:05 ` Måns Rullgård 2012-01-27 14:05 ` Måns Rullgård 2012-01-27 14:09 ` Ming Lei 2012-01-27 14:09 ` Ming Lei 2012-01-27 15:45 ` stephane eranian 2012-01-27 15:45 ` stephane eranian 2012-01-27 15:54 ` Will Deacon 2012-01-27 15:54 ` Will Deacon 2012-01-27 15:57 ` stephane eranian 2012-01-27 15:57 ` stephane eranian 2012-01-27 16:59 ` Will Deacon 2012-01-27 16:59 ` Will Deacon 2012-01-27 17:03 ` stephane eranian 2012-01-27 17:03 ` stephane eranian 2012-01-27 17:10 ` Will Deacon 2012-01-27 17:10 ` Will Deacon 2012-01-27 17:16 ` stephane eranian 2012-01-27 17:16 ` stephane eranian 2012-01-29 17:36 ` stephane eranian 2012-01-29 17:36 ` stephane eranian 2012-01-30 9:40 ` Ming Lei 2012-01-30 9:40 ` Ming Lei 2012-01-30 10:24 ` stephane eranian 2012-01-30 10:24 ` stephane eranian 2012-01-30 13:43 ` stephane eranian 2012-01-30 13:43 ` stephane eranian 2012-01-30 14:49 ` Ming Lei 2012-01-30 14:49 ` Ming Lei 2012-01-30 16:02 ` stephane eranian 2012-01-30 16:02 ` stephane eranian 2012-01-30 16:08 ` Måns Rullgård 2012-01-30 16:08 ` Måns Rullgård 2012-01-30 17:15 ` stephane eranian 2012-01-30 17:15 ` stephane eranian 2012-01-30 17:24 ` Will Deacon 2012-01-30 17:24 ` Will Deacon 2012-01-30 17:45 ` stephane eranian 2012-01-30 17:45 ` stephane eranian 2012-01-30 19:14 ` Will Deacon 2012-01-30 19:14 ` Will Deacon 2012-01-30 20:45 ` stephane eranian 2012-01-30 20:45 ` stephane eranian 2012-03-07 2:49 ` Ming Lei 2012-03-07 2:49 ` Ming Lei 2012-03-07 9:48 ` Will Deacon 2012-03-07 9:48 ` Will Deacon 2012-01-27 14:06 ` Ming Lei 2012-01-27 14:06 ` Ming Lei 2012-01-18 10:18 ` Russell King - ARM Linux 2012-01-18 10:18 ` Russell King - ARM Linux
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='CACVXFVM472hz+na7o2wJr1CPq-W=YB7i0UwtrsUf62+ryzWp8A@mail.gmail.com' \ --to=ming.lei@canonical.com \ --cc=a.p.zijlstra@chello.nl \ --cc=b-cousson@ti.com \ --cc=dave.long@linaro.org \ --cc=eranian@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mans@mansr.com \ --cc=mingo@elte.hu \ --cc=santosh.shilimkar@ti.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: 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.