: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, | [EMAIL PROTECTED]
:\ / 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 "[EMAIL PROTECTED]"
