Re: tcp_isn_tick() / dummynet() callout madness ?

From: Scott Long (scottl_at_samsco.org)
Date: 01/31/05

  • Next message: M. Warner Losh: "Re: [current tinderbox] failure on sparc64/sparc64" 
    Date: Sun, 30 Jan 2005 23:49:43 -0700
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

    Poul-Henning Kamp wrote:

    > In message <20050130191410.R62670@odysseus.silby.com>, Mike Silbersack writes:
    >
    > One of the things I would like to see is for the callout api to gain
    > a mutex pointer.
    >
    > If the pointer is not null, a mtx_trylock() is atempted, if it fails
    > a taskq is used to execute this callout, otherwise the function is used
    > as usual.
    >

    Taskqueues really are very non-deterministic and a poor choice for
    periodic events. They really are only suitable for events that are
    uncommon and don't require any sense whatsoever of urgency. While the
    callout API doesn't have any real-time guarantees, there is an
    assumption that assigned callouts will be generated with a reasonable
    amount of accuracy and consistency, and not be held up by a task that
    has an indefinite run time. Either a new dedicated kthread-based task
    needs to be created for what you propose, or the simplier approach can
    be taken of just deferring callouts that fail the trylock test to the
    end of the list.

    Scott
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: M. Warner Losh: "Re: [current tinderbox] failure on sparc64/sparc64"