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>