Yeah, I do obviolusly know that arch64 uses more RAM than it's 32bit's counterpart, but i'm just still puzzled about the following:
I've recently changed from arch32 to arch64 and where arch32 used 45mb when logged in to X(musca) and arch64 using 134mb. Both values is - buffers/cache!
Well, I then just thought that it was the processes running that used so much ram, but after running ps_mem.py, htop and ps aux, then I can see that im using under 30MB.
Then I thought that it was the kernel, but dmesg lists that it uses under 5MB.
Then I thought that it was some kernel caching thinggy, but /proc/meminfo lists only 17MB under slab(and where half of that is freeable).
Lastly I checked the kernel modules running with lsmod, and there where only a few which had big size numbers(radeon etc), and they were in the ranged of about 900000, which I would believe is in bytes and hence about 0.9mb, since if it where in KB, then it would be far too much, but additionally, then I read somewhere that lsmod uses number of pages for it's size values, but that dosen't add up, since then each of those modules would be using way to much, as each page is 4kb?
I'm not at home right now, so I cannot post the exact values described above, but I have looked at them soo much, so that I know that the estimates above is correct, but I can still post them when i get home if someone wants to look at the exact values.
Btw, I do have 4GB, so it's not about that, but I just wants to know where my MBs are spent in detail....
Also, I have not added any extra demons, services, apps or anything and without starting X, then it's 116MB without buffers/cache, and where the exact same setup on arch32 used about 35!...
I wish there where some kinda tool or script which could list kernel memory used and how much memory each kernel module takes up and such, as im at a complete loss about where my used MBs are ending up... (yeah, I know that everything is allready listed in various files under /proc, but im not wise enough to analyze and make sence of that yet...)
If anyone could give some input on this, then i'd really appreciate it!
Thanks in advance!
Last edited by mhertz (2010-10-29 10:48:36)
Seems natural to me (I've got a x86_64 and a i686 install).
Yeah, I know; I wasen't implying an arch bug, but just wanted to get to understand where those unaccountered MBs where spent... In the I686 version I could understand the memory usage patternt, but not so with X86_64... (of course that's because i'm not smart enough, but nonetheless and hence my post for better understanding this... )
Last edited by mhertz (2010-11-01 21:24:50)
Sorry, I misunderstood your post.
Anyway, The main disadvantage of 64-bit architectures is that relative to 32-bit architectures, the same data occupies more space in memory (due to swollen pointers and possibly other types and alignment padding). from http://en.wikipedia.org/wiki/64-bit#Pros_and_cons
No prob; thanks anyways mate!
The thing im requesting further elaberation on is this:
free -m reports 134MB used without caching, but I cannot see more used than:
ps_mem.py lists under 30MB used(total=private+shared). (and max 50MB if going by htop).
dmesg lists the kernel to use under 5MB.
/proc/meminfo lists slab as using 17MB(half of that reclaimable; I don't know how free -m deals with that).
lsmod shows only 4 big modules(and many small ones) with sizes in the range of highest 900000, which I guess is about 0.9mb.
That is maybe 60MB max and along way up to 134, so I am thinking that it's either some hidden kernel caching/reservation, or that the culprit is the kernel modules i.e.probably the radeon driver,but I don't know how to check that besides the size listed by lsmod, which dosen't show any big values, but the thing is also that I used the same driver on the I686 version and where the memory usage was at total 45MB, then im not sure that it's even that(unless the radeon driver uses many times more memory than the i686 version?).
I wish I knew how to meassure these things in detail...
Last edited by mhertz (2010-11-02 08:47:45)
I had the same problem, until I tried to build my own kernel (mainly for fun), and things got better than expected, I uses now 2× less memory, and still don't understand why
I'm french, don't mind my mistakes in english.
I uses now 2× less memory, and still don't understand why
That means it uses only half the ram it did before?
Just wanted to add that it isn't the ati foss driver which is using the unaccounted ram, as I tried to uninstall it, reboot and check 'free -m', and it was the same(115mb).
I then thought if it was an issue of the radeon.ko kernel module that is included with the kernel, and I then rebooted with KMS off, which dosen't load the radeon module, and that saved 10MB.
That's alittle bit, but still about 60MB left unaccounted for, so again, if someone knows what it is in the 64bit kernel that is using that unaccounted for memory(or how to find out), then I would greatly appreciate it!(i.e.used memory not listed in htop, ps aux, slabtop or in cache/buffers listed in the 'free' command).
Last edited by mhertz (2010-11-24 10:53:46)
I'm french, don't mind my mistakes in english.
Hmm, I've noticed that dmesg reports about 134MB memory reserved by the kernel(dmesg | grep Memory) on my 64bit arch install, but that on the same machine and everything the same, except using arch32, then the kernel reserved memory is only about 34MB!
I've always just thought that this memory gets released after the initial booting, but maybe some of it doesn't, and that's maybe where the used hidden memory is that I cannot locate?
Does someone have an idea about where to check for if some of that boot-time reserved memory isn't released, or e.g. just if you know for a fact that some of it isn't released, which then would solve the question of this thread i.e. where's the unaccounted memory being spent on arch64?
I think I know now what it is; On intel 64bit system with over 3gb, then by default 64mb is reserved for a software io tlb:
"Placing 64MB software IO TLB between ffff880005c00000 - ffff880009c00000"
...Cant belive i missed that from dmesg!