Date: Thu, 06 Feb 1997 15:40:13 -0800 From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: Simon Shapiro <Shimon@i-Connect.Net> Cc: "John S. Dyson" <toor@dyson.iquest.net>, freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Contigious (spelling?) allocation in kernel Message-ID: <199702062340.PAA02385@narnia.plutotech.com> In-Reply-To: Your message of "Thu, 06 Feb 1997 09:55:40 PST." <XFMail.970206131700.Shimon@i-Connect.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
> >Hi John S. Dyson; On 06-Feb-97 you wrote: > >> Take a look at contigmalloc() or vm_page_alloc_contig() >> as defined in /sys/vm/vm_page.c. These are almost >> guaranteed NOT to work after the system is fully up. > >Thanx. > >If you (or someone else) please elaborate on the last sentence, >please... Contigmalloc is only guaranteed to work when lots of physical memory is availible to allocate. It works a little bit to try to kick stuff around to make contiguous regions, but to rely on it working all the time to satisfy your allocation would be deadly. >I can re-structure the driver a bit (make it more risky), to >avoid the need for large contigious blocks, but the (obvious) >question is: Does the kernel malloc guarantee that allocations >smaller than (or equal to) a page are in the same page? Yes. A single virtual page always maps to a single physical page. You must use contigmalloc if you cross page boundaries. >Having a page or less, limits the Scatter/Gather operations in >the kernel, for most hardware, to 512 entries (segments). >Under high fragmentation, this can result in 256KB-2MB floating >limit. Actually, it gives you a floating limit between 2MB->2048GB unless you are talking about sending things that are not contiguous in the virtual address space and the granualiry of discontinuity is smaller than a page size. >While not a problem for most applications (mine >included), it is still a limit that is not absolutely necessary. If you need the space, allocate it up front with contigmalloc. Contigmalloc may someday be enhanced to succeed always if physical memory isn't exhausted, but the cost of such an operation under heavy load is extremely high, so you wouldn't want to use it often anyway (especially not if you had even lose real-time constraints). >Any opposing opinions (before I re-code the darn thing :-)? You should talk to John Dyson about anything you want to do to contigmalloc. The VM system is not your standard meat and potatoes and since John has already done some work on enhancing contigmalloc, he's the expert in this area. >BACKGROUND: One of my engineers, who is heavily involved in >Linux SCSI development is strongly opposed to calling malloc on >demand in a device driver. He quotes heavy performance >penalties, and worse; Failure (under heavy load) to obtain the >memory when needed. Malloc will always succeed in FreeBSD if you can sleep and have not run out of physical memory. The problem is that you don't always have a process context to sleep on (say your in an interrupt handler). In the new CAM based architecture, this isn't a problem since instead of sleeping in the driver when you run out of resources for some reason, you simply put the request back into the queue for a retry later. That retry will either use a resource that was freed by another transaction completing or its malloc call will succeed without any waiting involved. This assumes, of course, that you have pre-filled your pool with enough resources for the minimal level of performance so that a failure to malloc every once in a while isn't that big of a deal. Malloc in the FreeBSD kernel is fairly fast too. >Thanx, Simon -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702062340.PAA02385>