de0 doze off
scottl at samsco.org
Fri Sep 17 16:59:30 PDT 2004
Robert Watson wrote:
> On Fri, 17 Sep 2004, Raphael H. Becker wrote:
>>>Looks good. This may result in reduced stability, but it may also tell us
>>>specifically if there's a problem with the IFF_NEEDSGIANT mechanism.
>>two parallel wget saturate the link to an average of ~12MByte/sec
>>(netstat 1) for some hours. seems to work perfect now, constant full
>>I transferred around 180 copies of the miniinst.iso and ran a md5 on
>>lots of the file to detect xfer-errors, nothing failed, no more errors.
> So it sounds like there may be a race in the IFF_NEEDSGIANT implementation
> -- perhaps a lost task event when queueing occurs while the task is
> running. I'll need to come up with a patch that allows us to make sure
> this is the case, and get back to you tonight or tomorrow.
> Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> robert at fledge.watson.org Principal Research Scientist, McAfee Research
Looking at the taskqueue implementation, it looks like it takes care to
make sure that enqueued tasks don't get lost. If one CPU calls
taskqueue_enqueue() while the other CPU is servicing the queue, the
worst that should happen is that the new task doesn't run until the next
clock tick. This will of course create some latency, but you should be
able to avoid this by making sure that your handler polls itself for
new work before returning. If tasks are truly being lost then I'll be
very interested to figure it out, but given the common use of taskqueues
in the storage drivers, I think that the implementation is pretty solid.
More information about the freebsd-current