From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 23:59:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34F5416A4CE; Fri, 17 Sep 2004 23:59:30 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 871E043D39; Fri, 17 Sep 2004 23:59:27 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i8HNx0Ki014712; Fri, 17 Sep 2004 17:59:00 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <414B7A13.3060805@samsco.org> Date: Fri, 17 Sep 2004 17:58:11 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-current@freebsd.org cc: "Raphael H. Becker" Subject: Re: de0 doze off X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 23:59:30 -0000 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@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. Scott