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?