[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: kmem_alloc_wait and memory pools questions
From:       Matthew Dillon <dillon () apollo ! backplane ! com>
Date:       2008-06-27 16:51:32
Message-ID: 200806271651.m5RGpW8C030680 () apollo ! backplane ! com
[Download RAW message or body]


:On Friday 27 June 2008 10:43:29 Roman Divacky wrote:
:> hi
:>
:> I have two questions:
:>
:> 1) is kmem_alloc_wait() expensive operation? I believe it's not
:> very cheap looking at the code but I want confirmation
:>
:> 2) is there a support for memory pools in FreeBSD?
:>
:> to give you a little background why I am asking this. In NetBSD Andrew
:> Doran claims that replacing allocation from a memory submap with an
:> allocation from a memory pool for exec*() args he can speedup exec*()
:> by ~25%
:
:I think what is called a "memory pool" in NetBSD refers to their pool(9) 
:API.  This is more or less the same as our uma(9).  Whether or not this 
:is what you are looking for - I don't know.
:
:> I wonder if this applies to FreeBSD too so I am investigating it a
:> little.
:
:-- 
:/"\  Best regards,                      | mlaier@freebsd.org
:\ /  Max Laier                          | ICQ #67774661

    Yes, and yes.  The key issue here is that kmem_alloc*() futzes with the
    kernel page tables every single time, and on a SMP box that is 
    extremely expensive due to the cpu synchronization required.

    A memory pool, on the other hand, tends to simply reuse kernel memory
    which has already been mapped.  Much less page table futzing goes on.

    I don't know if UMA is exactly equivalent for allocations that large
    (exec-args is 64-128K), but someone else can answer that.  The key
    issue with regards to converting exec args is that you still must
    limit the pool size and block if too many processes are trying to
    exec at once, or you will really unbalance physical (and on i386 KVM)
    memory use.  A pool able to hold 8-16 allocations, and hence handle 8-16
    simultanious exec()s, is plenty big enough.

    (DragonFly did this about a year ago, it is definitely worth doing).

						-Matt

_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]