The other day, Tommi Komulainen pointed out to me that GSlice is using more memory than memchunks for him after bootup of the N770. Now, GSlice is supposed to be faster than memchunks, yes. And its supposed to scale far better across multiple threads. In the long run it is also meant to be more efficient in terms of memory consumption.
However, that is mostly due to the fact that many code portions which use GMemChunk are keeping their own never-freeing trash stacks. Such code should now be migrated to the GSlice API and the trash stacks should be removed. GSlice maintains its own working set memory in per-thread trash stacks. Home grown trash stacks will just waste memory and clutter up the cache lines.
Also, using separate GMemChunks prevents chunks of equal sizes from being shared across a program, this again wastes memory and clutters up the cache lines.
Because of the long-term wastage that GMemChunk application tends to build up, significant memory savings from GSlice are actually only to be expected for longer running programs which certainly is not a scenario met directly after N770 boot up ;)
That being said, the original check-in of the slab allocator in the GSlice code does behave a bit greedy actually. Basically, it allocates a new page (4096 bytes on IA32) per every different size, memory chunks are allocated at (chunk sizes are aligned to 8 bytes on IA32). That means, initially allocating 8 + 16 + 24 + 32 + 40 bytes in separate chunks does require opening up of 5 caches, so it uses 5 * 4096 = 20KB already. I’ve tuned the most recent CVS version now to do more economical caching, so the above scenario now ends up at roughly the power-of-2 sums of 8*8, 16*8, 24*8, 32*8 and 40*8, which is approximately 1.6KB and can all be allocated from a single memory page. While this is a significant memory saver, it also does have some performance impacts. However, in all test scenarios on my machine, the GSlice performance didn’t drop by more than 5%. That’s probably bearable, considering how significant the savings are.
- This blog is mostly about technical stuff related to my projects.My homepage has contacts and a project list.
-
Blogroll
-
Categories
-
Recent Posts
-
Recent Comments
- Dave Miller on 20.10.2008 Bugzilla Utility buglist.py
- Mike on 20.10.2008 Bugzilla Utility buglist.py
- Artem on 09.09.2008 The Manju Project
-
Archives
- October 2008 (2)
- September 2008 (1)
- July 2008 (1)
- June 2008 (3)
- May 2008 (1)
- April 2008 (2)
- February 2008 (1)
- October 2007 (2)
- September 2007 (3)
- August 2007 (2)
- July 2007 (2)
- June 2007 (4)
- April 2007 (3)
- March 2007 (1)
- January 2007 (2)
- December 2006 (2)
- November 2006 (2)
- October 2006 (1)
- September 2006 (2)
- August 2006 (1)
- July 2006 (1)
- June 2006 (1)
- May 2006 (2)
- April 2006 (3)
- February 2006 (2)
- January 2006 (1)
- December 2005 (3)
- November 2005 (2)
- September 2005 (1)
- August 2005 (3)
- July 2005 (6)
- June 2005 (12)
2 Comments
“That’s probably bearable, considering how significant the savings are.”
saving 14KB per app on startup ?The savings are application specific, my blog entry just outlines an example calculation that shows how the savings can be significant (compared to the size actually allocated by the user code).