Date: Fri, 6 Nov 2015 11:08:44 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Hans Petter Selasky <hps@selasky.org> Cc: Rasool Al-Saadi <ralsaadi@swin.edu.au>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: Timing issue with Dummynet on high kernel timer interrupt Message-ID: <CA%2BhQ2%2Bj0WiGgzV119M1ZQiXP5Z7fq7deVxDPkOhvTc7hpTETKw@mail.gmail.com> In-Reply-To: <563C786C.1050305@selasky.org> References: <6545444AE21C2749939E637E56594CEA3C0DCCC4@gsp-ex02.ds.swin.edu.au> <5638B7B5.3030802@selasky.org> <6545444AE21C2749939E637E56594CEA3C0DE7FF@gsp-ex02.ds.swin.edu.au> <563B2703.5080402@selasky.org> <6545444AE21C2749939E637E56594CEA3C0E0BD9@gsp-ex02.ds.swin.edu.au> <563C6864.2090907@selasky.org> <CA%2BhQ2%2Bhm2z0MkB-8w5xJM7%2Biz13r_ZjwmpZBnb30_D_48gaf-w@mail.gmail.com> <563C786C.1050305@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 6, 2015 at 10:52 AM, Hans Petter Selasky <hps@selasky.org> wrote: > On 11/06/15 09:50, Luigi Rizzo wrote: >> >> On Fri, Nov 6, 2015 at 9:44 AM, Hans Petter Selasky <hps@selasky.org> >> wrote: ... >>> Hi, >>> >>> The C_DIRECT_EXEC flag reduces task switching overhead, that you don't >>> have >>> to wakeup a thread to wakeup the dummynet worker thread. It affects >>> timing. >> >> >> Hans, >> thanks for the explanation. >> >> Can you clarify the behaviour of C_DIRECT_EXEC ? >> Does this mean that the task is run within some common >> thread instead of a dedicated one ? > > > Hi Luigi, > > C_DIRECT_EXEC means that the timer callback is executed directly from the > fast interrupt filter of the timer or IPI. > >> >> If so, for this type of task (dummynet may run at high rate >> and use a significant amount of cpu time) it may be a good >> idea to remove C_DIRECT_EXEC altogether. > > > The ipfw dummynet code is not run from the timer callback. It is run from a > taskqueue. I suspect there is likely a bug somewhere. At the moment it is > not clear to me if there is a bug in the callout subsystem, that the when > the timer is started with 1 tick delay it doesn't kick in until after 50ms > or so at HZ=4000. Or if the dummynet's task is doing a lot of work for 50ms. > I think we need some more information to nail this one. It certainly does not run for 50ms, but it might occasionally keep the thread busy for some 10-50us (I doubt it is longer than that) and possibly cause the reschedule request to fall into the interval where it should actually run. So if your theory is correct, it may well be that the callout system sees the request "in the past" (possibly as a result as some incorrect wraparound, or undefined behaviour on integer wraps) and then the event is only recovered when the callout wheel (or whatever is the underlying implementation) happens to go again through the entry. What is so magic in the values we see (400 or 600 or 40ms) i have no idea. cheers luigi > --HPS > >> >> cheers >> luigi >> > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+-------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhQ2%2Bj0WiGgzV119M1ZQiXP5Z7fq7deVxDPkOhvTc7hpTETKw>