Date: Sat, 23 Jul 2005 12:17:21 -0700 From: Peter Wemm <peter@wemm.org> To: freebsd-amd64@freebsd.org Cc: Petri Helenius <pete@he.iki.fi> Subject: Re: kernel memory Message-ID: <200507231217.21681.peter@wemm.org> In-Reply-To: <200507231212.24708.peter@wemm.org> References: <42DFDCCA.8050207@he.iki.fi> <42DFF043.3090203@he.iki.fi> <200507231212.24708.peter@wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 23 July 2005 12:12 pm, Peter Wemm wrote: > On Thursday 21 July 2005 11:58 am, Petri Helenius wrote: > > Peter Wemm wrote: > > >2GB for paged kernel memory. But in addition we access memory via > > > the direct map area to avoid the need for temporary mappings in > > > many cases. uma (malloc, mbufs) etc use this, as does the sfbuf > > > temporary mapping system. > > > > So there is no limitation for malloced memory? Say if my driver > > would like to have 4 or 8 gig lookup cache that would work? > > AARGH. I've just found a bug/feature in the memory allocator. > > There are two code paths, one for small (<PAGE_SIZE) allocations, > which uses the direct map allocations instead of kvm allocations, and > the other large chunk allocator that simply allocates pages at a time > from kvm. :-( > > I suspect this is because malloc's semantics depend on objects being > contiguous. The direct map method would allocate physically > discontiguous pages. > > So, if you allocated your lookup cache in <4K chunks, you could have > as much as you like. :-/ Make that <= 4K. A 4K allocation should be fine. But I suspect that is still going to be a pain to deal with. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507231217.21681.peter>