Re: kisskb: FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Dec 10, 17:33
On Thu, 2015-12-10 at 07:05 +, Vineet Gupta wrote: > On Thursday 10 December 2015 12:05 PM, nore...@ellerman.id.au wrote: > > FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Dec 10, 17:33 > > > > http://kisskb.ellerman.id.au/kisskb/buildresult/12564629/ > > > > Commit: Add linux-next specific files for 20151210 > > 8225f4e85cb03daea14661380745886ce01fd83a > > Compiler: arc-buildroot-linux-uclibc-gcc (Buildroot 2015.08.1) 4.8.4 > > > > Possible errors > > --- > > > > include/linux/jiffies.h:10:33: fatal error: generated/timeconst.h: No such > > file or directory > > make[2]: *** [kernel/bounds.s] Error 1 > > make[1]: *** [prepare0] Error 2 > > make: *** [sub-make] Error 2 > > > > No warnings found in log. > > Hi Michael, > > It is weird that no other arch build show similar errors. > Building same linux-next on my machine seems to be fine as well. That is weird. I'll ask it to rebuild it and see if it happens again. Do you build with -j? > From looking at logs it looks like some sort of a make / paralle jobs timing > issue > at build farm. > > P.S. Could you also update system to also cc lkml and > linux-snps-arc@lists.infradead.org for such errors. I'll add the arc list, I don't like to cc lkml so as not to annoy people with too many error mails. cheers ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
percpu irq APIs and perf
Hi Marc / Daniel / Jason,
I had a couple of questions about percpu irq API, hopefully you can help answer.
On ARM, how do u handle requesting per cpu IRQs - specifically usage of
request_percpu_irq() / enable_percpu_irq() API.
It seems, for using them, we obviously need to explicitly set irq as percpu and
as a consequence explicitly enable autoen (since former disables that). See
arch/arc/kernel/irq.c: arc_request_percpu_irq() called by ARC per cpu timer
setup.
if (!cpu) {
irq_set_percpu_devid() <--- disables AUTOEN
irq_modify_status(IRQ_NOAUTOEN) <-- to undo side-effect of above
request_percpu_irq
}
enable_percpu_irq
I don't see pattern in general for drivers/clocksource/ and/or arm_arch_timer.c
for PPI case.
Further there is an ordering requirement as in request_percpu_irq() needs to be
called only for the first calling core, and enable_percpu_irq() on each one. If
enable is done ahead of request it obviously fails.
For ARC I've historically used a wrapper arc_request_percpu_irq() [pseudo code
above] - which has an inherent assumption (now realize fragile) that it will be
called on core0 first thus guaranteeing the ordering above. This is true for
timer, IPI etc but not for other late probed peripherals - specially perf.
Infact ARC perf probe open codes on_each_cpu() to ensure irq request is done
locally first.
But this all falls apart, when perf probe happens on coreX (not core0), causing
enable to be called ahead of request anyways. This is what I'm running into now.
I think the solution is to call request_percpu_irq() on whatever core hits
first and call enable_percpu_irq() from a cpu up notifier. But I think the
notifier won't run on boot cpu ? Or is there a better way to clean up all this
mess.
FWIW, I see this issue on 3.18 kernel but not latest 4.4-rcX because in 3.18
arc perf probe invariably happens on coreX (due to init task migration right
after clocksource switch - something which doesn't happen on 4.4 likely due to
recent timer core changes).
Thx,
-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: kisskb: FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Dec 10, 17:33
On Thursday 10 December 2015 02:34 PM, Michael Ellerman wrote: > That is weird. I'll ask it to rebuild it and see if it happens again. > > Do you build with -j? I did now - but still no error at my end. >> From looking at logs it looks like some sort of a make / paralle jobs timing >> issue >> at build farm. >> >> P.S. Could you also update system to also cc lkml and >> linux-snps-arc@lists.infradead.org for such errors. > > I'll add the arc list, I don't like to cc lkml so as not to annoy people with > too many error mails. OK - thx. -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: percpu irq APIs and perf
Hi Vinnet,
On 10/12/15 09:25, Vineet Gupta wrote:
> Hi Marc / Daniel / Jason,
>
> I had a couple of questions about percpu irq API, hopefully you can help
> answer.
>
> On ARM, how do u handle requesting per cpu IRQs - specifically usage
> of request_percpu_irq() / enable_percpu_irq() API.
> It seems, for using them, we obviously need to explicitly set irq as
> percpu and as a consequence explicitly enable autoen (since former
> disables that). See arch/arc/kernel/irq.c: arc_request_percpu_irq()
> called by ARC per cpu timer setup.
Indeed. The interrupt controller code flags these interrupts as being
per-cpu, and we do rely on each CPU performing an enable_percpu_irq().
So the way the whole thing flows is as such:
- Interrupt controller (GIC) flags the PPIs (Private Peripheral
Interrupt) as per-CPU (hwirq 16 to 31 are replicated per CPU) very early
in the boot process
- request_percpu_irq() only occurs once, usually on the boot CPU (but
that's not a requirement)
- each CPU executes enable_percpu_irq(), which touches per-CPU
registers. This usually involves a CPU notifier to enable/disable the
interrupt when hotplug is on.
> if (!cpu) {
>irq_set_percpu_devid() <--- disables AUTOEN
>irq_modify_status(IRQ_NOAUTOEN) <-- to undo side-effect of above
>request_percpu_irq
> }
> enable_percpu_irq
>
> I don't see pattern in general for drivers/clocksource/ and/or
> arm_arch_timer.c for PPI case.
You can have a look at arch/arm/smp/smp_twd.c which is probably less
cryptic.
> Further there is an ordering requirement as in request_percpu_irq()
> needs to be called only for the first calling core, and
> enable_percpu_irq() on each one. If enable is done ahead of request
> it obviously fails.
Yup.
> For ARC I've historically used a wrapper arc_request_percpu_irq()
> [pseudo code above] - which has an inherent assumption (now realize
> fragile) that it will be called on core0 first thus guaranteeing the
> ordering above. This is true for timer, IPI etc but not for other
> late probed peripherals - specially perf.
>
> Infact ARC perf probe open codes on_each_cpu() to ensure irq request
> is done locally first.
>
> But this all falls apart, when perf probe happens on coreX (not
> core0), causing enable to be called ahead of request anyways. This is
> what I'm running into now.
>
> I think the solution is to call request_percpu_irq() on whatever core
> hits first and call enable_percpu_irq() from a cpu up notifier. But I
> think the notifier won't run on boot cpu ? Or is there a better way
> to clean up all this mess.
I think that's pretty much it.
See drivers/perf/arm_pmu.c::cpu_pmu_request_irq() for example.
> FWIW, I see this issue on 3.18 kernel but not latest 4.4-rcX because
> in 3.18 arc perf probe invariably happens on coreX (due to init task
> migration right after clocksource switch - something which doesn't
> happen on 4.4 likely due to recent timer core changes).
Hope this helps,
M.
--
Jazz is not dead. It just smells funny...
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: kisskb: FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Dec 10, 17:33
On Thu, 2015-12-10 at 14:58 +0530, Vineet Gupta wrote: > On Thursday 10 December 2015 02:34 PM, Michael Ellerman wrote: > > That is weird. I'll ask it to rebuild it and see if it happens again. > > > > Do you build with -j? > > I did now - but still no error at my end. OK. It rebuilt OK the second time: http://kisskb.ozlabs.ibm.com/kisskb/buildresult/12564629/ So there might be a gremlin in the Makefiles somewhere. cheers ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: kisskb: FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Dec 10, 17:33
Hi Michael, On Thu, 2015-12-10 at 14:58 +0530, Vineet Gupta wrote: > On Thursday 10 December 2015 02:34 PM, Michael Ellerman wrote: > > > That is weird. I'll ask it to rebuild it and see if it happens again. > > > > Do you build with -j? > > I did now - but still no error at my end. I always build our kernels with -j4 or even -j8 depending on the machine I use and I've never seen issues with parallel building. Latest I tried was 4.4-rc4. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: kisskb: FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Dec 10, 17:33
On Thu, 2015-12-10 at 14:16 +, Alexey Brodkin wrote: > Hi Michael, > On Thu, 2015-12-10 at 14:58 +0530, Vineet Gupta wrote: > > On Thursday 10 December 2015 02:34 PM, Michael Ellerman wrote: > > > That is weird. I'll ask it to rebuild it and see if it happens again. > > > > > > Do you build with -j? > > > > I did now - but still no error at my end. > > I always build our kernels with -j4 or even -j8 depending on the machine I use > and I've never seen issues with parallel building. I just saw the same failure on another arch, so it doesn't look like its anything to do with arc. cheers ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: percpu irq APIs and perf
Hi Marc, On Thursday 10 December 2015 03:26 PM, Marc Zyngier wrote: > Hi Vinnet, > > On 10/12/15 09:25, Vineet Gupta wrote: >> Hi Marc / Daniel / Jason, >> >> I had a couple of questions about percpu irq API, hopefully you can help >> answer. >> >> On ARM, how do u handle requesting per cpu IRQs - specifically usage >> of request_percpu_irq() / enable_percpu_irq() API. >> It seems, for using them, we obviously need to explicitly set irq as >> percpu and as a consequence explicitly enable autoen (since former >> disables that). See arch/arc/kernel/irq.c: arc_request_percpu_irq() >> called by ARC per cpu timer setup. > Indeed. The interrupt controller code flags these interrupts as being > per-cpu, and we do rely on each CPU performing an enable_percpu_irq(). > > So the way the whole thing flows is as such: > - Interrupt controller (GIC) flags the PPIs (Private Peripheral > Interrupt) as per-CPU (hwirq 16 to 31 are replicated per CPU) very early > in the boot process Thx for your reply and the pointers irq-gic.c seems to be doing irq_set_status_flags(irq, IRQ_NOAUTOEN); So it is setting NOAUTOEN, which is already the case per side effect of irq_set_percpu_devid(). No harm in making it explicit. So this will make __setup_irq() skip irq_startup() and instead rely on enable_precpu_irq() to be called even for the local core. I think we can make percpu irq API a bit easier to use. (1) First thing which request_percpu_irq() does is check for irq_settings_is_per_cpu_devid(). Thus irq_set_percpu_devid() can be built into the API itself eliding the need to set it apriori. (2) It seems that disabling autoen by default for percpu irq makes sense as evident from drivers/net/ethernet/marvell/mvneta.c where users want to control this. However the comment there is misleading /* Even though the documentation says that request_percpu_irq * doesn't enable the interrupts automatically, it actually * does so on the local CPU. * * Make sure it's disabled. */ Either sme core code is clearing NOAUTOEN or calling enable_precpu_irq() making request_percpu_irq() enable it. IMHO it makes more sense to make autoen explicit in the API. Perhaps introduce a API flavour, which takes the autoen as arg. It could take flags to make it more extensible / future safe but that will be an overkill I think. Do let me know what you think and I can send RFC patches to same effect. Thx, -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
