From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 4 11:45:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A8501065672 for ; Fri, 4 Feb 2011 11:45:27 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 00D848FC0C for ; Fri, 4 Feb 2011 11:45:26 +0000 (UTC) Received: from ur.dons.net.au (ppp203-122-198-32.lns6.adl6.internode.on.net [203.122.198.32]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p14BjOjc061976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Feb 2011 22:15:24 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Fri, 4 Feb 2011 22:15:24 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53A394ED-7C2E-4E4B-A9A7-CB5F1B27DBE3@gsoft.com.au> To: Ivan Voras X-Mailer: Apple Mail (2.1082) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-hackers@freebsd.org Subject: Re: Scheduler question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 11:45:27 -0000 On 04/02/2011, at 21:48, Ivan Voras wrote: >> I am wondering if this is a scheduler problem (or I am expecting too = much :) in that it is not running my libusb thread reliably under load. = The other possibility is that it is a USB issue, although I am looking = at using isochronous transfers instead of bulk. >=20 > I'm surprised this isn't complained about more often - I also = regularly see that file system activity blocks other, non-file-using = processes which are mostly CPU and memory intensive (but since I'm not = running realtime things, it fell under the "good enough" category). = Maybe there is kind of global-ish lock of some kind which the VM or the = VFS hold which would interfere with normal operation of other processes = (maybe when the processes use malloc() to grow their memory?). I guess for an interactive user anything less than 100msec is probably = not noticeable unless it happens reasonably regularly when watching a = video. > Could you try 2 things: >=20 > 1) instead of doing file IO, could you directly use a disk = device (e.g. /dev/ad0), possibly with some more intensive utility than = dd (e.g. "diskinfo -vt") and see if there is any difference? OK, I'll give it a shot. > 2) if there is a difference in 1), try modifying your program to = not use malloc() in the critical path (if applicable) and/or use = mlock(2)? It doesn't allocate memory once it's going, everything is preallocated = before the data transfer starts. I'll have a go with mlock() and see what happens. Thanks :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C