this one feels like it has such a simple answer, but somehow i am missing it
lshw, dmidecode and memtest86 all tell me i have 2x 4 GiB (or 4096 MB) of RAM which i have also seen with my eyes when dismantling the machine. however, free, htop and conky all agree that i have 6.47 GiB (6624 MiB from free). i get that there is a conversion between GB and GiB and i would even swear that in ubuntu 16.04 (i’m now running bodhi based on 18.04) my readings were closer to (if not exactly) 7.45.
when i first noticed this, i ran across a reddit answer to a similar question that pointed concerned folks to linux ate my ram! i get the ideas of buffer and cache. htop makes both pretty clear. i know that’s not what i’m looking at.
In that link it says you should use free -m and check how much is available. That said, I’m sure conky uses a generic free command or whatever is the most used one.
right. in general i was moreso interested in the total column. i understand well enough from htop what is being used and by what process. i just don’t get why the total is so different from what i know to physically be present.
Ah yes, I forgot the actual question. So all the hardware or RAM specific software is showing the correct amount of RAM, but free does not. Weird, but it shouldn’t be a big issue, I guess.
that is one of the pages i had gone through before posting. i wanted to make doubly and triply sure that i was looking at all of the possible angles. both of those report the same 6.47 (or so) as free.
Maybe you could write a program that allocates 7GB RAM and see how it goes. If the system truly assumes your RAM to max out at about 6.5GB then the program should crash.
I just wrote a program that allocates ~7GB RAM and terminates after 60 seconds. You can download and run it with the following one-liner:
the second link at the bottom has some good info about what the system reserves. i have stared at too many dmesg | grep outputs for now. i will have to get back to it in the morning with a fresh perspective. thanks for the links.
in the once upon a time i recall reading an article about this, but didn’t really process that in regards to my memory question. i think this may be part (if not all [i’ll wait to see if anyone else comes up with another option]) of the answer.
the third link that @Akito shared suggested looking at the output of dmesg | grep Memory. mine is below and that does show some memory available for use by my graphics device.
i think my final remaining question about all of this is how the memory “usable by graphics device” is determined and allocated. both htop and conky do a good job of showing used + buffers and cache (like in the link you shared) so it was just about 1 gb that i was wondering about. it really isn’t a big issue in the end. more of a curiosity than anything.
Yes. I’m not an expert on this field, but I think I remember that the IGP decides itself how much it wants. I don’t know if it is fixed though, may also be a possibly variable amount of memory it operates with. I guess it should be described somewhere in a more technical description regarding e.g. Intel IGPs.
there is probably a good description from intel. that’s a helpful suggestion. so far my search for “shared memory” in general have yielded very generic info. i will try looking into the make and model. thanks.
That’s sadly the downsite of searching something on the internet. Mostly people need or want only the necessary minimum. If something dives into a topic deeper, the curve of how much it interests people goes down drastically. One of the curses of today’s society, I guess.
perhaps so. i believe i have the a pdf of the manual on my storage drive. i usually give them a decent read-through when i first get a computer, but that has been a couple of years. i don’t recall any one that i have looked through going into such detailed memory allocation info, but that is also a possible line of inquiry.
i think part of the reason i started this topic was that i was under a similar impression to the op of the serverfault link you posted that free’s reporting of available memory should list everything. instead (thanks to this discussion) i have discovered that the answer is a bit more nuanced when it comes to system reserves etc.
an interesting turn of events after a fresh uefi install to an ssd. free -m now shows:
total used free shared buff/cache available
Mem: 7795 1220 618 182 5956 6096
Swap: 2047 0 2047
i originally assumed that meant that the video memory issue was different or perhaps misread on the previous install, but dmesg | grep Memory shows the same output with regards to video memory with a minor increase in system reserves and the major difference being total memory available:
