Date: Thu, 15 Nov 2001 14:48:49 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Chris Ptacek <cptacek@sitaranetworks.com> Cc: "'freebsd-hackers@freebsd.org'" <freebsd-hackers@freebsd.org> Subject: Re: kernel malloc questions... Message-ID: <3BF44651.2583430C@mindspring.com> References: <31269226357BD211979E00A0C9866DAB02BB9745@rios.sitaranetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris Ptacek wrote: > I am trying to malloc a large amount of memory for a KLD during load and the > malloc keeps failing. I am trying to malloc 64-128MB for a memory pool for > a project I am working on. My system has 196MB of memory and the KLD is > loaded at startup so I am relativly sure that I have enough memory to > satisfy the request. > > I guess the questions are: > > Is there a limit to the amount of memory the kernel (including > modules) can malloc? Yes. There are two limits. One is based on the amount of mappings available, which limits your total swap plus physical memory that you can allocate. The second one is 1G, because that the size of the KernelVirtual Address space. > If there is how do I change this amount? The kernel virtual address space can be increased. The handbook give almost all (but not quite) the information needed. See the -current list archives. > I am currently using M_NOWAIT, would using M_WAITOK be better? M_NOWAIT means that you are not permitting it to sleep; this means that you are willing to accept a failure, rather than have the process on whose behalf the call is being made put to sleep. You say it's a KLD, but fail to tell us if it is a device driver in the module. I'll assume that it is. Then the answer is that you can't sleep unless you create a kernel process to use as a sleep context. > Would this end up hanging my system in this case? It depends on your usage; see above. M_WAITOK is supposed to wait until the memory is available; but in fact, it does not wait forever, like you would want. If it fails after a number of retries, it gives up. This is a semantic change that came in early in the 4.x branch, It was never really justified to my satisfaction, other than someone had a wait case that failed once in a while, and didn't want to understand the code fully enough to fix it. So no matter how you call it, you have to be prepared for a failure. Knowing why it fails would probably help you: the failure can only occur if it traverses the map looking for a large enough space and can't find it. > Would I be better off mallocing many smaller buffers into a > memory pool (64 1MB buffers)? It depends on your usage. If the memory is necessary to be contiguous, then you could do worse than to follow Alfred's advice. In any case, if you can do it as smaller chunks, you will get better utilization of the kernel memory map, and will be more likely to not need a large contiguous region. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BF44651.2583430C>