From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 1 13:36:05 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 787D916A4D2 for ; Sat, 1 Jul 2006 13:36:05 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail32.syd.optusnet.com.au (mail32.syd.optusnet.com.au [211.29.132.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7F0844369 for ; Sat, 1 Jul 2006 12:34:57 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail32.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k61CYj30019904 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 1 Jul 2006 22:34:45 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k61CYj4v011069; Sat, 1 Jul 2006 22:34:45 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k61CYio1011068; Sat, 1 Jul 2006 22:34:44 +1000 (EST) (envelope-from peter) Date: Sat, 1 Jul 2006 22:34:44 +1000 From: Peter Jeremy To: Hans Petter Selasky Message-ID: <20060701123444.GD8447@turion.vk2pj.dyndns.org> References: <200605271102.19799.hselasky@c2i.net> <200606302029.28563.hselasky@c2i.net> <20060630203226.GG734@turion.vk2pj.dyndns.org> <200607011044.54872.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uxuisgdDHaNETlh8" Content-Disposition: inline In-Reply-To: <200607011044.54872.hselasky@c2i.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 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:36:05 -0000 --uxuisgdDHaNETlh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 m= aybe >an extra memory copy in most cases. The idea is to allocate less than or= =20 >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. >The most important thing is to keep memory allocations of constant size. F= or=20 >example under my USB system, all memory is allocated at attach. There is n= o=20 >longer allocation and freeing of memory during usage, with a few exception= s.=20 Are you talking about USB device attach - which could happen at any time whilst the system is running - or USB bus attach? >I was thinking I could pre-allocate 2-4MB for the USB system, then make a= =20 >list of freed memory blocks, and then search this list first, before=20 >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. "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). --=20 Peter Jeremy --uxuisgdDHaNETlh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEpmvj/opHv/APuIcRAryCAJ9Y/Xk3IMRd1KWxs1/hJivW5Cv54wCgn79C vGZ0NLw5uDP+8ZLkBaNWZ5k= =0mb4 -----END PGP SIGNATURE----- --uxuisgdDHaNETlh8--