To be honest, I've wondered before why "About This System" shows less memory than is installed on the system. I think it's worth considering the integer value of the installed RAM rather than whatever calculation is being done here. Especially since there is no help test or other information presented to the user to explain what's calculating this difference.

I think the problem here is that it tries to calculate it by what it's available or what can be counted, but I don't think that UEFI or the BIOS cared to report to the Linux kernel how much they have used ore reserved.
Probably the Linux kernel too doesn't report to higher up tools how much it's using or reserving for internal things.
On my laptop with only 8 GiB or RAM the difference is only 307.2 MiB (8192-7884.8), if that 7.7 GiB is accurate as that single digit after the floating point might be as inaccurate as for files (that I reported here):
https://bugs.kde.org/show_bug.cgi?id=498820
But on other computers that have 16, 32, 64 or more GiB or RAM the difference could be even higher and more confusing.
At some point I assume it could even make sense, like actually being possible with using a smaller RAM stick.

I don't remember unfortunately how much it showed for a friend of mine that has a laptop with 16 GiB and an AMD APU for which you can choose from UEFI how much to give.
On mine I have no such option to choose.

I assume the Info Center is trying to calculate it by doing something like this:
https://stackoverflow.com/a/20348977
Which for it gives:
8031396
MemTotal:        8031396 kB
Which i assume they are Kibibytes, for which DDG tells me that are the same as 7.659336 GiB:
https://duckduckgo.com/?q=8031396+MiB+in+GiB&t=ffab&ia=web
If KDE is using again that round up or down (up in this case) to have just one digit after the floating point, then probably that's why it's shown as 7.7 GiB.

Like some of the answers there point out, it's just better to use dmidecode if you want accurate memory size.

And there's also lshw that like dmidecode, gives and accurate answer and requires sudo
https://stackoverflow.com/a/63961771
And also to be installed, which for me it wasn't.
Or like how this guy modified it:
https://askubuntu.com/a/1530772

This answer also gives me the correct 8 GiB size and it doesn't seem to require sudo like dmidecode or lshw:
https://stackoverflow.com/a/53186875
Even though pasting it in the terminal seem to have some problems.

We're just showing the truth here. The marketing tricks are unfortunate, but we don't have any control over them.

Our options are:
1. Show the truth and confuse people who both care about technical details and also don't know about how marketers lie about memory and storage capacities (i.e. that "256 GB SSD" never exposes 256GB of space to the OS; it's the same with memory)
2. Lie like the marketers do, and make people think they have more memory than they actually do, compared to the other places like Info Center where we have to show the truth for technical reasons.

As such, I'm inclined to choose #1 and say this is intentional.

After some discussion, an avenue we can pursue is to show an informational tooltip that would explain that the hardware is reserving some amount of space

.

Someone actually started an MR to address this and show the actual hardware RAM size but it got stuck unfortunately

(In reply to Nate Graham from comment #4)
> We're just showing the truth here. The marketing tricks are unfortunate, but
> we don't have any control over them.
First, no, you're not showing the truth here!
The only truth shown here is the unit, being GiB, which is correct.
The value is not the truth as the calculation is wrong, it doesn't take all the memory already reserved (used) to reach the proper total!

JEDEC is a standardization organization that mandates the use of binary (base 2) to calculate the values of sizes.
On the unit notation it uses (recommends) 3 prefixes: K, M and G.
K being 1024 (2 to the 10th power)
M being  K to the power of 2, where K = 1024.
G being  K to the power of 3, where K = 1024.
A standard that we have since 2002:
https://en.wikipedia.org/wiki/JEDEC_memory_standards#JEDEC_Standard_100B.01
We are lucky that all RAM manufacturers, without exception, follow the JEDEC standard!
Maybe because all programming languages and programmers work with bits and bytes (base 2) and everything would be a mess and a nightmare with the base 10 that doesn't aling nicely.
And it's not only RAM manufacturers that either follow the JEDEC standard or just binary units without any relation to JEDEC, but also CPU GPU and hard drive manufacturers when it comes to chaches sizes.
While it's harder to get a confirmation after a few searches for the chaches sizes, I think the "Where used (mainly)" part of this answer confirms it:
https://cseducators.stackexchange.com/a/4446
And these 2 answers confirms it for the RAM sizes only:
https://www.reddit.com/r/explainlikeimfive/comments/13sc135/comment/jloxsvx/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
https://www.reddit.com/r/explainlikeimfive/comments/13sc135/comment/jloykan/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

UEFI / BIOSes seem to follow the JEDEC standard too, except that hey prefer to show MB instead of just M as recommended in the standard:
How UEFI / BIOSes is showing it -> 8192 MB + type + frequency:
https://4.bp.blogspot.com/-aOQT-q1cVnk/VTIU5qb2kqI/AAAAAAAAGWk/z2Rt2NWWXJg/s1600/20645-01-asus-uefi-11380626.jpg
https://www.ocinside.de/media/uploads/asrock_b450m_steel_legend_uefi_1.jpg

So, when it comes to physical RAM sticks, for which I opened this bug report, the RAM sticks manufacturers (vendors) + marketers + UEFI / BIOS manufacturers never lie as they count in base 2 (of course with the exception of the units which are a bit wrong, showing MB or GB when JEDEC recommends M and G and IEC recommends MiB and GiB).

The ones that clearly lie / trick you, are the hard drive manufactures which prefer to use base 10, so K being 1000 instead of 1024, when it comes to the big, non-cache part.
They can even rob / trick you of a whopping 2 TiB when they sell you a 22 TB hard drive:
https://duckduckgo.com/?t=ffab&q=22+TB+in+TiB&ia=web
But still there, the small 256 or 512 chaches they come with should be MiB and not MB.

And then there are also the networking equipment manufacturers that lie / trick you, that are even worse than the hard drive manufacturers as they use bits instead of bytes, so their numbers are not only 1.024 bigger like hard drive manufacturers show, but a whopping 8 times.
A 100 Mb/s being in reality just 12.5 MiB/s.
You get the idea how much different is for 1,000 of for 5,000 Mb/s connections.

> Our options are:
> 1. Show the truth and confuse people who both care about technical details
> and also don't know about how marketers lie about memory and storage
> capacities (i.e. that "256 GB SSD" never exposes 256GB of space to the OS;
> it's the same with memory)
> 2. Lie like the marketers do, and make people think they have more memory
> than they actually do, compared to the other places like Info Center where
> we have to show the truth for technical reasons.
>
> As such, I'm inclined to choose #1 and say this is intentional.
I'm also inclined to choose #1, to show the truth!
And for consistency and easier calculation just use the binary (base 2, so 2 to some power) everywhere, not only the RAM memory sizes.
So also for storage and download / upload speeds.
For me it would be fine for connection speeds too, so 12.5 or 125 MiB/s.
But I also agree that for some consistency with the tricks in the real world, that we cannot change, to also show those, like KDE Partition Manager does for storage devices  or for networking equipment where people might know better the 100 / 1000 / 1 Gbps connections instead of the real binary speeds.

But the big problem here and why I opened this bug report is that the total memory size is not shown correctly here.
It shows the allocatable / usable one!
I want to see the real one, the full / complete / total one, like the UEFI / BIOS of the computer shows!
UEFI / BIOS, being much more low level than QT / KDE software and even than the Linux kernel, knows better what is the total size.
Probably it also has the advantage of being able to count it before it starts reserving a portion of it like when the computer boots and after when the Linux kernel reserves a portion too of it.

I also looked a bit how others have decided to show it...

How Windows 7 is showing it -> 8.00 GB (7.75 GB usable) for 64-bit version:
https://2.bp.blogspot.com/_8qMdy9GxQw8/TTBBpquV2tI/AAAAAAAAAro/BvfWmL2GmP8/s1600/windows-7-system-properties.gif
Or for 32-bit version, whith a big difference, probalby because it was reserving a lot for the GPU:
https://i.ytimg.com/vi/2guGEiAUGNQ/maxresdefault.jpg
Or for 4 GiB 32-bit version:
https://www.groovypost.com/wp-content/uploads/2014/01/WEI-Tool-Windows-7.png

How Windows 10 is showing it -> 8.00 GB (7.85 GB usable):
https://i.imgur.com/gXfqa9f.png
https://www.javelin-tech.com/blog/wp-content/uploads/2020/03/find-computer-name.png
How Windows 11 is whowing it -> 8.00 GB (7.71 GB usable):
https://www.groovypost.com/wp-content/uploads/2021/09/1-Windows-11-About.png

How Android is showing it -> 3.9 GB/8GB used (and the reserved one on a new line):
https://i.ytimg.com/vi/lfCp52y6UFU/maxresdefault.jpg
https://www.androidauthority.com/how-to-check-ram-in-android-3346256/

So Android tries to show everything on that page in a few lines, the available one, the used one and the total one.
Since it can show the reserved one too, probably there the firmware and the bootloader report to the OS how much they have reserved from it.
Unlike Windows that just shows the total one and leaves the used and available one to other tools, like the task manager (resource / system monitor there).
Which makes sense when you have 2 different tools, one to show the system information and one to should the resources usage.
Which Plasma has too, but I think this this information page is mingling things, showing resource usages that belong to the System Monitor.
Even more since the hardware section should show the hardware as it is, not how it is used or how much of it it is used.
For example the CPU in the same Hardware section is shown as:
8 × Intel® Core™ i5-8250U CPU @ 1.60GHz
Which besides the stupid 8 x (as as I have only one) is showing the correct base frequency.
Not the current one which is only 400 MHz or the maximum one that sometimes is reached, which is: 3.40 GHz:
https://www.intel.com/content/www/us/en/products/sku/124967/intel-core-i58250u-processor-6m-cache-up-to-3-40-ghz/specifications.html

BTW, this is how the Memory is shown in Hardinfo 2 + CPU-X programs:
https://imgur.com/iJ9sZuP
I'm sure that if you tried them on your systems, they will have different values than mine, but in any case they should match the values in UEFI / BIOS firmwares or in Windows if you have a dual-boot setup.

(In reply to TraceyC from comment #5)
> After some discussion, an avenue we can pursue is to show an informational
> tooltip that would explain that the hardware is reserving some amount of
> space
Since many users either use Windows too on other computers, the same with dual-boot or are coming from there and they already seen the parentheses after  value + unit, so the "(x.xx GB usable)", I think a lot of users already know that not all memory remain to be usable by the OS and whatever programs run on it.
And since most of the Linux users are pretty tech-savvy we can also assume that they know this fact.
But to cover all bases, for users that didn't use Windows or other OS like youngsters or they didn't pay the attention before some kind of information about some memory being reserved is good to have.

Though to not annoy people who already know this the tooltip seems the best idea to me.
This is still the summary page and more info can be seen on the dedicated Memory page.
As for the Memory usage by the OS, there are additional tools available one in Plasma itself: System Monitor, which is also the second page after the summary page (About This System).
And for other tech / Linux-savvy people there is also Mission Center:
https://missioncenter.io/
That has a great memory page.
Or Hardinfo 2
https://github.com/hardinfo2/hardinfo2
That shows in addition to the physical total one, how much it's available to the Linux OS.

In my opinion the toolthip could show a message like:
Some of it is reserved by the hardware
Or:
Some of it is reserved by the firmware (UEFI / BIOS)
Or, similar to Hardinfo 2 and Windows, with calculation:
7.7 available to Linux
7.7 usable
But here, since it has more chances to not be integer than the total phicical one, I wish the precision would be one digit higher
So instead of showing 7.7 available (or usable), if it's not exactly 7.70, then it would be nice to have 2 digits after the floating point, like in Windows:
https://i.imgur.com/gXfqa9f.png
I'm one of the persons that sometimes take numbers and put them in Krunner or DDG to substract them from others or to convert them to other units, so if I want to now how much exactly is reserved, it would be better to have the second digit after the floating point too.
Windows does it for when the second digit is zero too:
https://www.javelin-tech.com/blog/wp-content/uploads/2020/03/find-computer-name.png
Maybe for consistency with the total physical memory, but I would not care to see the zero in this case too.

Right, I had forgotten that the discrepancy isnt due to GB -> GiB conversion, but the lower addressable space.

I think we can show something simple like "8 GB (7.7 GiB usable)"

Hi guys!
I see that there's an open merge request here:
https://invent.kde.org/plasma/kinfocenter/-/merge_requests/234
To avoid reopening this bug report, I want to give my feedback now.
I don't want just something that "reduces the confusion" as there is no confusion on my part.
I know exactly much RAM I have in the computer.
And I know that the firmware and the Linux kernel is reserving a part of it, without telling the userspace tools how much.

It's normal and I don't care about that, I care about what was / is the total, that has nothing to do with what is reserved!
So, form all my research and a bit of commands modifications, there is one way to do it that requires superuser privileges:
sudo dmidecode -t memory | awk '/Size:[[:space:]]No[[:space:]]Module[[:space:]]Installed/ {next}/Size:/ {print $0}';

I made it skip the lines with 'No Module Installed', as those are empty slots, but I don't know how to make it sum things if more than one is installed and I could not test it anyway as I have just one stick or RAM installed.
But since Infocenter -> Memory page also seems to call dmidecode without asking me for the password, I thing the superuser privileges is not a problem, though counting and summing up the amounts on every stick probably still is.

And based on these 2 answers here:
https://stackoverflow.com/a/53186875
https://stackoverflow.com/a/76641120
There are 2 ways to calculate it without sudo.

totalmem=0; for mem in /sys/devices/system/memory/memory*; do [[ "$(cat ${mem}/online)" == "1" ]] && totalmem=$((totalmem+$((0x$(cat /sys/devices/system/memory/block_size_bytes))))); done;
echo $((totalmem/1024**3)) GB \(${totalmem} bytes\);

totalmem=$(lsmem -b --summary=only | sed -ne '/online/s/.* //p');
echo $((totalmem/1024**3)) GB \(${totalmem} bytes\);

If the real total memory size is shown, there is not reason for the tooltip to even exist, but it's ok if you want to show it how much is available / usable to the system or to explain that some of it is reserved by the firmware and the Linux kernel.

Since I can't edit the last comment, I found out that if you modify the dmidecode piped awk command to $2 instead of $0, like:
sudo dmidecode -t memory | awk '/Size:[[:space:]]No[[:space:]]Module[[:space:]]Installed/ {next}/Size:/ {print $2}';
It gives just the number in GiB.
I don't know what it gives when there are more sticks, but I assume it will give a new line for each stick with its size.

(In reply to Harald Sitter from comment #7)
> Someone actually started an MR to address this and show the actual hardware
> RAM size but it got stuck unfortunately

Yes, that was me attempting to address this same issue with https://invent.kde.org/plasma/kinfocenter/-/merge_requests/194

Glad that it's being superseded by https://invent.kde.org/plasma/kinfocenter/-/merge_requests/234

I like how it looks in that last picture with the "usable..." in parentheses and the tooltip providing the general info.

BTW, I looked again in the UEFI firmware of my laptop and the 1 stick of 8 GiB memory it's displayed like this:
Installed: 8192 MB
Available: 8110 MB
So 82 MiB are already gone while just booting in UEFI.
Maybe that's how much is needed for that interface and if you don't boot into it, they will not be taken.
This is the only UEFI / BIOS that I have seen showing an available meory there.

There isn't an option for how much memory the GPU can use, but there's this:
Software Guard Extensions
Which I had disabled as I don't trust it and I don't have any software that uses it.
If I enable it I can set the "Enclave" memory size with radio buttons between:
32 MB
64 MB
128 MB
I tried with 32 and 128 MB and rebooted to see if there's any difference in the memory size displayed in Info Center, but there was none.
Maybe because only one digit after the floating point is too small to notice such difference.
So this SGX:
https://en.wikipedia.org/wiki/Software_Guard_Extensions
Can also reserve a portion of the memory, if you think you want to mention that too.

Thinking of how systemd-analyze displays something like this:
Startup finished in 5.500s (firmware) + 8.419s (loader) + 7.863s (kernel) + 4.109s (userspace) = 25.893s 
graphical.target reached after 3.958s in userspace.
I reached the conclusion that the kernel must report to systemd how much time it took to load and maybe it has something like that for the memory too, which led me to this answer:
https://stackoverflow.com/a/72624877
From where I got and ran this command:
sudo dmesg | grep  Memory:
That gave me this:
[    0.193581] Memory: 7921644K/8283144K available (16384K kernel code, 2484K rwdata, 11752K rodata, 4140K init, 4968K bss, 348612K reserved, 0K cma-reserved)
Which I transformed into MiB for better understanding:
[    0.193581] Memory: 7735.98MiB/8089.008MiB available (16MiB kernel code, 2.425781MiB rwdata, 11.47656MiB rodata, 4.042969MiB init, 4.851563MiB bss, 340.4414MiB reserved, 0 MiB cma-reserved)

If we subtract the reserved one from the total possible one, we get the usable one:
8192 MiB - 340.4414 MiB = 7851.5586 MiB = 7.667538 GiB
Mission center says: 7.66
KDE's System Monitor says: 7.7 GiB
Info Center says: 7.7 GiB

I is a bit unclear to me if this reserved memory means just the one of firmware or the one reserved by the firmware + the one reserved by the kernel.
Looking a bit further to see if we get get the one reserved (used) by the kernel only, I got to this answer:
https://unix.stackexchange.com/a/97265
From which I got this command and its output:
sudo grep Slab /proc/meminfo
Slab:             246428 kB
Which is: 240.6523 MiB

IMO, the firmware usage is the reserved memory - kernel memory (this slab thing), so:
340.4414 MiB - 240.6523 MiB = 99.7891 MiB.
Which probably makes sense and may be somewhat accurate as I could see a difference of 82 MiB reported directly in UEFI's interface (see my previous message). The lab thing doesn't take into account the memory reserved (used) by modules, which I don't know yet how to calculate, but the answer says it should be showhere between 16 MiB and 32 MiB. The difference here being 18 MiB (100-82).

This in case you want to display here or in the system Monitor how much is reserved by the firmware+kernel  and/or how much is reserved by each one of them.
I'm not sure how correct is everything, but that's all that I could gather from the bits and pieces from all the answers available.
Hopefully in the future the kernel itself will have a way to account and report more accurately all the memory used by the firmware and by itself + its modules.

Git commit f44af69b07ed19d076819fe4cc84e5777747d957 by Oliver Beard.
Committed on 25/02/2025 at 17:07.
Pushed by olib into branch 'master'.

kcms/about-distro: Add help property to Entry & show total amount of installed memory in MemoryEntry
This provides additional information to the user, with a new help tooltip that clarifies the displayed values as is contextually appropriate.
For example, if the shown message is "32 GB of RAM (31.3 GB usable)", the tooltip will elucidate that some memory is reserved for use by system hardware.

M  +4    -0    CMakeLists.txt
M  +5    -0    kcms/about-distro/src/CMakeLists.txt
M  +5    -0    kcms/about-distro/src/Entry.cpp
M  +3    -0    kcms/about-distro/src/Entry.h
M  +127  -17   kcms/about-distro/src/MemoryEntry.cpp
M  +8    -1    kcms/about-distro/src/MemoryEntry.h
M  +5    -0    kcms/about-distro/src/ui/main.qml

https://invent.kde.org/plasma/kinfocenter/-/commit/f44af69b07ed19d076819fe4cc84e5777747d957