From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 1 13:31:09 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57BC716A40F for ; Sat, 1 Jul 2006 13:31:09 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.swip.net [212.247.155.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B76843D64 for ; Sat, 1 Jul 2006 13:31:06 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== X-Cloudmark-Score: 0.000000 [] Received: from mp-217-132-211.daxnet.no ([193.217.132.211] verified) by mailfe13.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 56717174; Sat, 01 Jul 2006 15:31:04 +0200 From: Hans Petter Selasky To: Peter Jeremy Date: Sat, 1 Jul 2006 15:31:10 +0200 User-Agent: KMail/1.7 References: <200605271102.19799.hselasky@c2i.net> <200607011044.54872.hselasky@c2i.net> <20060701123444.GD8447@turion.vk2pj.dyndns.org> In-Reply-To: <20060701123444.GD8447@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607011531.11061.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: contiguous memory allocation problem 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: Sat, 01 Jul 2006 13:31:09 -0000 On Saturday 01 July 2006 14:34, Peter Jeremy wrote: > On Sat, 2006-Jul-01 10:44:54 +0200, Hans Petter Selasky wrote: > >Yes, but scatter and gather will add extra complexity to the driver, and > > maybe an extra memory copy in most cases. The idea is to allocate less > > than or equal to a page of memory, and then avoid the problem? > > The idea is to allocate multiple disjoint pages of physical memory. > The USB hardware is capable of supporting this and page translation > hides the lack of contiguousness from userland. I don't see why > additional memory copies would be required. Because most USB device drivers depend on a contigous buffer. In your case one would have to implement something similar to "uiomove()" for copying, that will do the scatter and gathering ? > >The most important thing is to keep memory allocations of constant size. > > For example under my USB system, all memory is allocated at attach. There > > is no longer allocation and freeing of memory during usage, with a few > > exceptions. > > Are you talking about USB device attach - which could happen at any > time whilst the system is running - or USB bus attach? I am talking about the USB device attach. > > >I was thinking I could pre-allocate 2-4MB for the USB system, then make a > >list of freed memory blocks, and then search this list first, before > >allocating new memory. > > That strikes me as wasteful. Currently, umass needs something like > 64K (or maybe 128K) and ulpt needs a few KB (they are the only USB > devices I normally use). I would be surprised if the peak USB RAM > requirement was more than 256K for most people. Yes, but don't forget high-speed USB transfers. They require larger buffers. For example 1024 bytes for ULPT is too little. The interrupt rate will be so high, that it is unrealistic to transfer 20MB/s using 1024 byte interrupts. My rewritten ULPT now uses "2*(1<<17)" buffers. > "vmstat -m" on my > systems shows that the current biggest consumer is devbuf - with > 3-4MB. Most other consumers are orders of magnitude smaller than this > (though my video capture card grabs about 4MB RAM when it's in use). --HPS