Messages in this thread | | | Date | Thu, 3 Apr 2008 22:53:43 +0530 | From | "Nitin Gupta" <> | Subject | Re: [PATCH 3/6] compcache: TLSF Allocator interface |
| |
On Tue, Mar 25, 2008 at 12:26 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> Yeah, it also suffers from a horrible coding style, can use excessive > amounts of vmalloc space, isn't hooked into the reclaim process as an > allocator should be and has a severe lack of per-cpu data making it a > pretty big bottleneck on anything with more than a few cores. > > Now, it might be needed, might work better, and the scalability issue > might not be a problem when used for swap, but still, you don't treat > any of these points in your changelog. >
I will add these points to changelog. This project is meant for small systems only. So, scalability is not an issue.
> FWIW, please split up the patches in a sane way. This series looks like > it wants to be 2 or 3 patches. The first introducing all of TLSF (this > split per file is horrible). The second doing all of the block device, > and a possible last doing documentation and such. >
Ok. I will resend with better splitting.
> Also, how bad was kmalloc() compared to this TLSF, we need numbers :-) > >
I have posted performance numbers at: http://code.google.com/p/compcache/wiki/AllocatorsComparison
Data Summary:
Peak Memory Usage:
* Ideal: 24947 KB * TLSF: 25377 KB * KMalloc(SLUB): 36483 KB
So, KMalloc uses ~43% more memory than TLSF!
- Nitin
| |