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