https://bugs.kde.org/show_bug.cgi?id=500412
--- Comment #2 from John <ilikef...@waterisgone.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.
