On Tue, Aug 01, 2017 at 10:26:11PM +0200, Mark Kettenis wrote:
> > Date: Mon, 31 Jul 2017 16:30:07 +0300
> > From: Artturi Alm <[email protected]>
> >
> > Hi,
> >
> > i've been annoyed by this inconsistency for years, and was wondering
> > if someone would have the time to explain why it is the way it is, or
> > give me any advice towards the correct&accepted fixes.
> >
> > i'll just copypaste some lines of code that should show what i mean:
> >
> > #define ARM_IRQ_HANDLER arm_intr
> >
> > ASENTRY_NP(irq_entry)
> > ...
> > bl ARM_IRQ_HANDLER
> > ... no r0 usage ...
> >
> > void (*arm_intr_dispatch)(void *) = arm_dflt_intr;
> >
> > void
> > arm_intr(void *frame)
> > {
> > /* XXX - change this to have irq_dispatch use function pointer */
> > (*arm_intr_dispatch)(frame);
> > }
> >
> > int
> > agtimer_intr(void *frame)
> > {
> > ... conditionally set the useless rc ...
> > return (rc);
> > }
> >
> > go void?
>
> Interrupt handlers return int such that they can be counted. You're
> missing the actual interrupt control implementtation in your analysis.
>
> Is this overengineered? Yes. Is this worth fixing? No.
I was already hoping noone would notice the mail, minutes after sending i
was laughing at myself, was matter of enocoffeeyet:)
anyway, here is a small description/bugreport of what lead me looking at there,
it was this systat output(i left only the relevant part of it) on cubie/A10:
Interrupts
184 total
sximmc0
sxie0
9 com0
67 tick
108 stattick
and what was weird, is that vmstat -i output is equal to systat-output w/
rest of the SoCs i tested with, so ~200 for agtimer&timer, and ~228 for
dmtimer, while for sun4i sxitimer they're off around 30tick/50stattick,
as you can see below.
# uname -a && sysctl kern.{clockrate,timecounter.hardware} && vmstat -i | grep
tick
OpenBSD cubie.my.domain 6.1 GENERIC#28 armv7
kern.clockrate=tick = 10000, tickadj = 40, hz = 100, profhz = 1024, stathz = 128
kern.timecounter.hardware=sxitimer
irq22/tick 207575 99
irq23/stattick 336786 162
OpenBSD cubie2.my.domain 6.1 GENERIC#28 armv7
kern.clockrate=tick = 10000, tickadj = 40, hz = 100, profhz = 1000, stathz = 100
kern.timecounter.hardware=agtimer
irq29/tick 1848340 198
OpenBSD wandb.my.domain 6.1 GENERIC#28 armv7
kern.clockrate=tick = 10000, tickadj = 40, hz = 100, profhz = 1000, stathz = 100
kern.timecounter.hardware=amptimer
irq29/tick 1571876 199
OpenBSD bbb.my.domain 6.1 GENERIC#28 armv7
kern.clockrate=tick = 10000, tickadj = 40, hz = 100, profhz = 1024, stathz = 128
kern.timecounter.hardware=dmtimer
irq68/tick 5011375 225
maybe ^this is something to fix? separate clock.c out of intr.c,
and go for freebsd style timer drivers where they use one shots
rather exclusively iirc..? (+the obv. freerunning counter ofc.), now
that'd allow some more consolidated code for the timers/timecounters.
(i'm not pointing out the obvious hz*2 'issue' here i think we have on armv7;).
-Artturi
