Date: Tue, 16 Sep 2014 17:53:52 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Alexander Motin <mav@freebsd.org> Cc: Bret Ketchum <bcketchum@gmail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: 9.1 callout behavior Message-ID: <CAJ-Vmo=m5LG73Z5kPmy%2B1NF0ZBxSemMTH5r8GirhNMnN9Ry-KQ@mail.gmail.com> In-Reply-To: <CAJ-VmonuWd5XbUdKo7P8cGha32dEhmvm0L0H1Ckasw9CC56=vQ@mail.gmail.com> References: <CAGm6yaTEFECTYVb94A13TaXMPSLtKLpTbw4iNdgd8SuNF1QDaA@mail.gmail.com> <CAJ-Vmokrchy4pXLvZ21sCV09fQUdYKeUYCEH1U1NdfDBxhyJQg@mail.gmail.com> <5295A261.2060403@FreeBSD.org> <CAGm6yaRAPoiVXuv3HgvJCHBTUYGokLyRLb_n0MQEyRp%2BcJUrqA@mail.gmail.com> <CAGm6yaRRcS1e5b_uo4wq=ArSMxFuuTkrKTgOTcQC9nbLnYi6Yw@mail.gmail.com> <529F4409.9080403@FreeBSD.org> <CAGm6yaRFQZ69gQ_Jv0JG5-ru=XtROV5mz7kONC46LRYoe1XTVg@mail.gmail.com> <CAJ-VmonJg-Lsbijc1PnqKt%2BAfmjLxkQpXbKQ4R90bWq7QoXkJQ@mail.gmail.com> <CAGm6yaT=6b6AxDxgivP1jUBmNG1Ynrh58tvhhtZ-qW%2BMKpbj3w@mail.gmail.com> <CAGm6yaSQBVXEQ=8NNLjQ0-1q5jxpBeQT2GCUhhCa4_qqiPX=pQ@mail.gmail.com> <52A1B869.6080407@FreeBSD.org> <CAJ-VmokdyubZLWfp7jub6LqCT%2BZwx0bO4vL6_G3L7CNngcYkQA@mail.gmail.com> <52A21AE9.5020803@FreeBSD.org> <CAJ-VmomRfSG7rXxKMEummRWET1bn_JZ=E7uG-Q1n-_H5NB-r5g@mail.gmail.com> <CAGm6yaRd41fXsFF1OTFyLQq7LAsbnZQ934-zYXNFsuCGCaMQqQ@mail.gmail.com> <52A731FD.8060307@FreeBSD.org> <CAJ-Vmom%2BFGB2OCBr9hwvZDL%2B44-fKhM7m97AvCSmN5nB6da%2BhQ@mail.gmail.com> <CAJ-VmonuWd5XbUdKo7P8cGha32dEhmvm0L0H1Ckasw9CC56=vQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16 September 2014 17:38, Adrian Chadd <adrian@freebsd.org> wrote:
> So, it did show up even if I say to run the callout on cpu #0 - any
> kind of load on that CPU and that callwheel still gets run on another
> CPU.
>
> What I next did was compile up KTR:
>
> include GENERIC
> ident TESTING
> options KTR
> options ALQ
> options KTR_ALQ
> options KTR_COMPILE=0xffffffff
>
> .. then enable KTR_CALLOUT, and I see:
>
> 4175 0 884780740167480 precision set for 0xffffffff818194f8: 0.01999997
> 4174 0 884780667893634 callout lock 0xffffffff818194f8 func
> 0xffffffff818191d0 arg 0xffffffff818194f8
> 4149 0 884780455441940 callout 0xffffffff818194f8 finished
> 4148 0 884780455441414 scheduled 0xffffffff818194f8 func
> 0xffffffff818191d0 arg 0xffffffff818194f8 in 561.4a5c984a
> 4147 0 884780455440600 precision set for 0xffffffff818194f8: 0.01999997
> 4132 0 884780373374060 callout lock 0xffffffff818194f8 func
> 0xffffffff818191d0 arg 0xffffffff818194f8
> 4103 0 884780170731868 callout 0xffffffff818194f8 finished
> 4102 0 884780170731468 scheduled 0xffffffff818194f8 func
> 0xffffffff818191d0 arg 0xffffffff818194f8 in 561.25c0f291
> 4101 0 884780170730948 precision set for 0xffffffff818194f8: 0.01999997
> 4086 0 884780089391348 callout lock 0xffffffff818194f8 func
> 0xffffffff818191d0 arg 0xffffffff818194f8
> 4058 0 884779886019688 callout 0xffffffff818194f8 finished
>
> .. and those 561.xxxx values are sbintime values.
>
> The delta looks like it's ~ 142mS, which is in line with what your
> callout routine reports. So the math to calculate the "next" event is
> bumping it along to that value instead of 100mS.
>
> I'm going to update one of these boxes to -HEAD and see if it's still
> a problem there.
So the test case uses callout_reset(), which is the "older" way of doing it.
What callout_reset() does is:
* convert to sbintime_t;
* set the callout precision to 0;
* set C_HARDCLOCK.
Now, C_HARDCLOCK doesn't read the last clock - it reads the last
per-cpu clock value. I have no idea if PCPU_GET(hardclocktime) is
_actually_ going to be equal across all CPUs - and boy if it isn't I'm
not going to fix it - but the point here is it's not going to be
updated very often when the system is idle and not receiving many
interrupts.
When I change the code to use callout_reset_sbt():
callout_reset_sbt(&cp->co, (SBT_1S * 100) / 1000, 0,
ticktock_callback, cp, 0);
.. and
callout_reset_sbt(&c.co, (SBT_1S * 100) / 1000, 0,
ticktock_callback, &c, 0);
To fire at the same interval that you did (hz / 10; so 100mS) then it
worked out perfectly fine.
-a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=m5LG73Z5kPmy%2B1NF0ZBxSemMTH5r8GirhNMnN9Ry-KQ>