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 >>speed. >> >>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. ScottReceived on Fri Sep 17 2004 - 21:59:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:12 UTC