The new issue of the LinuxJournal magazine features two articles, a preview of the 2.6 kernel and an article regarding memory allocation: Keeping memory requirements low can save your time and money. Here’s how to bend malloc() to your will.
Advanced Memory Allocation and Linux 2.6 Kernel Preview
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Sounds like they have some good stuff =)
The malloc article is fantastic. Very, very useful. Thanks for the pointer!
Their web site is not responding. I guess they have been “OSNews’d” already. 😉
There wasn’t much in the article on how GNU implements malloc in glibc, which was more what I was interested in.
One thing that always annoyed me was that malloc consistency checking isn’t enabled per default in glibc. This is most likely due to the “looser” algorithms used by glibc’s malloc implementation as opposed to the highly regimented approach seen on FreeBSD.
Because of this, Linux was vulnerable to things like the buffer overflow caused by a double free in zlib. FreeBSD was not.
Furthermore, the last time I looked at GNU malloc it had a rather nasty habit of storing a linked list which mapped free chunks of memory in the free memory itself. These chunks are often paged out, and consequently iterating the free list causes these chunks to be faulted into primary memory.
Well, I don’t mean to start a Linux/FreeBSD debate here. What I’m really saying is that the lack of coordination between the Linux VM team and the GNU glibc programmers handling the malloc() implementation shows very clearly the drawbacks of the “bazaar” approach, as the heap and VM implementations aren’t tightly integrated. The GNU malloc() implementation is not, last I looked, very well optimized for the Linux VM (although that’s not to say GNU is to blame. Calling the Linux VM a moving target is an understatement)
Two of the biggest advantages of 2.6 are going to be the included ALSA sound drivers and some dramatic improvements in latency that will make out-of-the-box distributions suitable for studio-quality audio.
I was very interested in this, as my past experiences with OSS showed Linux to be rather high-latency (although I’ll assume they’re refering to system responsiveness, which would only have an effect on audio jitter) Unfortunately, this article seems to be taken straight from the print edition, as it seems the relevant information may be here:
Preemptible kernel hacker Robert Love covers these and more on page 52.
In the past, the Linux mainline did not provide a low-latency sound API, similar to what’s provided by CoreAudio on OS X (which sports < 1 millisecond latency, even on non-pro hardware) and ASIO in Windows. It seems, however, that this will change with ALSA integration. ALSA has been shown to be lower latency than ASIO (but not lower than CoreAudio)
Bascule i tend to enjoy your comments so if yeah actually provoke a debate on where improvements can made to either Linux or FreeBSD then roll ahead. I’ve never used FreeBSD, i use Linux as my Desktop, though i’ve plenty of experience with Tru64 and IRIX.
It’s a great thing when we have OS’s of the quality of Linux and FreeBSD (other *BSD’s as well) that we can look under the hood. I wouldn’t know half of what i do about VM if it wasn’t for going through kernel source.
Are you running FreeBSD 5.0? what’s your general impression of it compare to either FreeBSD 4.* or even against Linux, i’ve got a spare hard-drive lying about and i was considering installing FreeBSD 5 on it.
The first comment at the end of the article should not be overlooked … if you are programming on an Intel CPU, <a HREF=”http://developer.kde.org/~sewardj/“>valgrind is an absolutely wonderful tool for debugging your app’s memory usage. It takes about 5 minutes to install, and then you can just type “valgrind ./myapp myargs” and as your app runs (slowly ;^)) most memory-usage errors get immediately flagged and descriptions of what they are and where they occurred get printed to stderr. This lets you find and fix your bugs immediately, instead of spending hours trying to figure out how your heap got corrupted. Highly recommended!
I am no techie but for the first time I have seen
some positive comments about techies staff which actually make you want to look further.
No flaming, no My OS is better than yours thing.
Refreshing guys really refreshing…
This is a test! Sorry!