Hi, On Wed, 3 Jan 2007 15:27:41 +0000 (UTC) Grant Edwards <[EMAIL PROTECTED]> wrote:
> The X server is using 56M of virtual memory with 33M resident > and 10M shared. Audacious is using 58M of with 14M resident > and 10M shared. "possibly" shared, to be exact. Whether it actually _is_ shared is not determined by ps. > > and the total memory they consume is used by all apps that use > > the libs. And, every one of those libs (apart from > > libaudacious) can reasonably be expected to be in use already > > on any desktop machine running X > > Nonsense. Audacious is using 44MB of non-shared virtual memory > on my system. 44MB out of 58MB is not shared. And what exactly was the nonsense? > I've no idea where the number 240M came from, you didn't hear > it from me. It's about 14MB of resident (6MB reduction in > "free" memory) on my system, which makes it the second largest > memory user (second only to the X server). Most probably not considering openoffice, Thunderbirg, Firefox/Opera & Co, right? In order to have huge VSZ, you just have to mmap a big fat file. And there you go. And what does that mean for the memory footprint of the program? Can you now call it a "resource hog"? Most likely not. > > So, anyone that says audacious is a resource hog is plain flat > > out wrong > > You don't think that 58M of virtual memory usage isn't a > resource hog when the X server only requires 56M and the next > largest program is 32M? Virtual memory _is_ a resource, > though not an expensive one. Errrm, to get back to my example above: Mmap'ing a file (and increasing your programs VSZ) is often much more elegant than classic procedural fseek'ing and fread'ing. Nothing, absolutely nothing makes that causing the program to become a "resource hog". The VM subsystem will care that exactly those parts of the file will be cached, buffered, accessed and (if needed) copied that are used. On the opposite, if the program was programmed to overcommit absurd amounts of memory, mmap'ing wrong/unneeded files or even doesn't free() correctly, then I would agree that it's likely to be a resource hog. But your points just aren't valid by themselves for that statement here. "Virtual Memory" is _not_ the summed up amount of RAM and Swap. It's an abstracted memory, on kernel code layer. Also, remember that Linux has per process page tables. So VSZ isn't expensive by any means -- up to the point that the process itself reaches the system's limit for virtual memory. And what does that mean for the "memory hog" claim? Nothing, absolutely nothing. -hwh -- gentoo-user@gentoo.org mailing list
