Subject: Re: Kernel memory allocation
To: Eduardo Horvath <eeh@NetBSD.org>
From: Park Chan-youn <phygeeks@gmail.com>
List: tech-kern
Date: 02/15/2005 13:48:16
Eduardo Horvath wrote:
> On Mon, Feb 07, 2005 at 11:32:13AM +0900, Park Chan-youn wrote:
> 
> 
>>I've tried to wrap all queue operations with spl, but it didn't worked. 
>>And I've already implemented a queue counter, and it shows the expected 
>>results.
> 
> 
> If you're doing a lot of allocs and frees then it's probably a good idea
> to set up and use a pool instead of malloc()/free().  It's more efficient
> and there's built-in debug.

Is it a general solution to fragmentation problems? Could you tell me 
where can I find a good example of the pool*() usage?

> Also, you should look at the malloc(9) manpage and make sure your USB
> device's interrupt level isn't too high.
> 

Well, I set the priority level of USB as IPL_BIO, which I followed the 
priority level of USB in ugen, generic usb driver of NetBSD. Do you 
think it is too high? If it is, what level do you recommend?

>>1) What is the meaning of 'fre' memory shown when called vmstat(8) with 
>>no option? Man page tells it is the size of the free list, but I can't 
>>understand what the free list is. Is it different from the free memory 
>>available?
> 
> 
> The free list is the list of pages that have been scanned and removed
> from active use.  This is pages of memory that can be immediately
> allocated.  malloc() and the pool*() routines take pages from this pool 
> and break them up to satisfy requests.  Those requests may result in
> fragmentation which may cause the memory pools to grow large.  That's
> probably what's happenning to you.
> 

Is there a way to see explicitly that the real problem is fragmentation, 
not just a guessing?