It seems that today I've some good news.
I've done some job.
Before I tried stuffs userspace
http://davit.altervista.org/malloc_new.c , then I improved my patch a
bit http://davit.altervista.org/uma_large_allocations.patch )
So, the situation is follow. System starts (before it doesn't), but
I've
oh, sorry I noticed that there's a typo.
In mtx_init(uma_mtx, Bitmap Lock, NULL, MTX_DEF);
you should replace uma_mtx with bitmap_mtx.
Davide
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To
On Fri, Jul 22, 2011 at 9:07 PM, Davide Italiano
davide.itali...@gmail.comwrote:
Hi.
I'm a student and some time ago I started investigating a bit about
the performance/fragmentation issue of large allocations within the
UMA allocator.
Benckmarks showed up that this problems of performances
Hi.
I'm a student and some time ago I started investigating a bit about
the performance/fragmentation issue of large allocations within the
UMA allocator.
Benckmarks showed up that this problems of performances are mainly
related to the fact that every call to uma_large_malloc() results in a
call
4 matches
Mail list logo