From owner-freebsd-current@FreeBSD.ORG Thu Jul 8 17:18:23 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 1AE2916A4CF for ; Thu, 8 Jul 2004 17:18:23 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4A4143D45 for ; Thu, 8 Jul 2004 17:18:22 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i68HGwds042340; Thu, 8 Jul 2004 10:16:59 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i68HGwnU042339; Thu, 8 Jul 2004 10:16:58 -0700 (PDT) (envelope-from dillon) Date: Thu, 8 Jul 2004 10:16:58 -0700 (PDT) From: Matthew Dillon Message-Id: <200407081716.i68HGwnU042339@apollo.backplane.com> To: Julian Elischer References: cc: phk@phk.freebsd.dk cc: mycroft@netbsd.org cc: ticso@cicely.de cc: "M. Warner Losh" cc: current@freebsd.org Subject: Re: speeding up ugen by an order of magnitude. 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: Thu, 08 Jul 2004 17:18:23 -0000 I explored the ugen code after reading Julian's original posting, and Bernd Walter's very informative postings. I also experimented a bit with s10sh (which uses ugen to download from digital cameras). Unfortunately my camera probably isn't the best test, and I didn't get any huge improvement in performance... but it didn't break either, and the 1K on-kernel-stack buffer definitely has to be fixed in any case. My conclusion is that while a lot of copying occurs inside the kernel, (in at least two places in fact), the overhead is inconsequential relative to the 1 ms scan issue in the USB controller. Remember, this is UGEN we are talking about here, not UMASS. It is not necessary to squeeze out every last bit of performance, only to make the performance 'reasonable'. The userland requests can certainly be made large enough (e.g. 64K, 128K, 1MB, whatever) (s10sh uses a 4KB ugen request, for example, but can be easily increased). The 1K buf[] in UGEN seems to be most responsible for screwing up performance. Increasing this buffer to a reasonable size and ignoring the problem of data copying that occurs in-kernel basically moves the entire problem into the xHCI device layer. I would recommend that you guys simply increase the size of the buffer in the UGEN layer for now, along the lines of Julian's patch or my patch, and then work on making the xHCI layer deal with large requests more efficiently as a separate stage. I email'd Julian the changes I made in DragonFly which include a sysctl to allow the buffer size to be set/changed on the fly. If you try to fix the half dozen or so buffer copying / busdma issues as a pre-req, you will wind up getting nothing done at all. -Matt