# 512 != 435 [solved]

## darker

I have a 512MB stick of RAM.  Why does conky say 435MB.  77MB seems like a rather large difference to me.

----------

## yaneurabeya

Maybe that's the amount of available RAM after your AGP card / System RAM usage is taken into consideration?

----------

## drphibes

 *yaneurabeya wrote:*   

> Maybe that's the amount of available RAM after your AGP card / System RAM usage is taken into consideration?

 

add this to your .conkyrc

```
no_buffers yes
```

----------

## darker

already there

----------

## TheCoop

you havent got a built-in gfx card have you?

----------

## drphibes

post the output of free -m and also what conky reports

----------

## darker

[quote=TheCoop]you havent got a built-in gfx card have you?[/quote]

No

[quote=drphibes]post the output of free -m and also what conky reports[/quote]

```

free -m

             total       used       free     shared    buffers     cached

Mem:           435        196        238          0         26         71

-/+ buffers/cache:         99        335

Swap:          486          0        486

```

```

conky: 99.4M / 435M

```

----------

## drphibes

nothing at all to do with conky.   your system is reporting 435M total memory for some reason.

i found this little program which will tell you how much memory you really have.   save it as memory.c 

and compile as indicated.  it might be some kernel configuration issue -- i really don't know.

```
/* 

   Copyright Bruce Allen 2005

   Released under GPL2

   Program to print out physical memory on a system. 

   

   [1] Put all of this into a file called memory.c

   

   [2] Compile it like this:

       gcc -o memory memory.c

   [3] Run it like this:

       ./memory

*/

#include <unistd.h>

#include <stdio.h>

int main(int argc, char **argv) {

  long pagesize=sysconf(_SC_PAGESIZE);

  long pages   =sysconf(_SC_PHYS_PAGES); 

  printf("size = %d number = %d bytes=%.0f\n", pagesize, pages,

        ((double)pagesize)*((double)pages));

  return 0;

}
```

or you can script it with python by saving this as memory.py:

```
import os

pagesize = os.sysconf("SC_PAGESIZE")

pages = os.sysconf("SC_PHYS_PAGES")

print "pagesize = %d, num pages = %d, total memory = %d" % (pagesize,pages,pagesize*pages)
```

and then running python memory.py

----------

## darker

```

./memory

size = 4096 number = 111426 bytes=456400896

```

Tomorrow when I have more time I'll look through the kernel config and see if anything is wrong there.

----------

## paranode

And your BIOS reports the correct amount I assume?

----------

## darker

Bios says

Memory Testing: 524288K

----------

## drphibes

boot into your bios and look at every setting in there.   something is reserving a nice chunk of your system memory for some purpose.   you usually see this with on-board graphics systems.    if you are using a separate graphics card, but also have an on-board graphics chip, perhaps you must disable the memory the on-board uses with a bios setting.   if it's not the video, something else is grabbing a nice chunk of your memory there.   the bios should tell you.

----------

## Denkino

do a 

```
cat /usr/src/linux/.config | grep HIGHMEM 
```

or, whereever your current kernel config is at.

I'm willing to bet that you have HIGHMEM4G=y set.

What happens with this flag is that, in systems with a LARGE physical set of memory, the system can't build a logical memory address large enough to access it all; so, it takes a chunk of memory, and sets it aside so that it can use it as a sort of 'index' onto the rest of the memroy.

if you have a gig or less, turn this feature off.. it's doing more harm than good.. you're loosing valuable memory.. especially if you are only running 512mb.

I've got a gig in my laptop, and with it turned on it gets 993 accessible megs.

here is a quick google search find explaining the HIGHMEM feature: http://strasbourg.linuxfr.org/jl3/features-2.3-2.html

In Kernel MenuConfig:

go into processory setup ->

    High Memory Support () ->

      and select OFF

rebuild the kernel, and install, and dance around merrily.

I'm assuming you've gone through the kernel dance before; refer to THE guide here http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=7 for assistance.

----------

## Denkino

A user with 1 gig of ram is a special case... cause, really, it's your call whether or not to do HIGHMEM4G or not..

With it ON, you get 933M of available space.

with it OFF, you get 883M of available space.

The advantage of loosing some of that space is that now you have one less check going on when resolving a logical address to a physical space adress.. but, on the other hand.. if you are on a process that could take lots of ram.. you might not mind a little hit on ram access...

but, if you have 1.5g or 2g .. or more.. this is a big thing... 

I have not seen any performance analysis on switchig this configuration for a 1g machine.. so, really, play with it till you feel like dancing.

----------

## Kaapeli

Or you could apply the 1glowmem patch on your kernel and use the whole gig without highmem support  :Smile: 

----------

## darker

HIGHMEM is not set, and I have 512MB, not 1G, so the LOWMEM patch would not really apply here.

----------

## Denkino

I wish I could say I had an exact reason why, or an exact breakdown of how to see why.. but I don't think it is a problem with your system.

https://forums.gentoo.org/viewtopic.php?t=175419

I came across this url which talks about what is really going on with memory management; the author has 512 and 503 listed as free.

 *Quote:*   

> Notice that I have 512 MB of memory in my machine, but only 503 is listed as available by free. This is mainly because the kernel can't be swapped out, so the memory it occupies could never be freed. There may also be regions of memory reserved for/by the hardware for other purposes as well, depending on the system architecture

 

The thing is... well, you'll never get Conky, free, the meminfo in proc, or anything to EVER say the total amount of 'PHYSICAL' memory available because, your userland will never be able to touch it all, let alone will it ever be freed to allow anywhere near that.. 

So, what do I think is using that 77mb of ram? hmm... big kernel? maybe. big modules? maybe. some huge service? maybe. I wouldn't know where to tell you to look to figure out where the consumption is.. 

More to the point, I don't think there is anything you can do about it if your system is configured the way you need to have it for everything to work. 

I would suggest booting up damn small linux to see what it tells you, or maybe compile a new kernel with NOTHING in it, and with all of your services turned off.. and see if that number changes... or even just pop the livecd in and see what free tells you there.

If you really want conky to say 512.. hard code it in there.

----------

## oggialli

 *Kaapeli wrote:*   

> Or you could apply the 1glowmem patch on your kernel and use the whole gig without highmem support 

 

At least for me, it kills Valgrind so it's a big no-no  :Sad: 

----------

## drphibes

i wonder if he could indicate what motherboard he is using.   also the system BIOS.

----------

## oggialli

Important question: is the whole amount of RAM visible in some AnotherOS?

----------

## darker

The motherboard is a Gigabyte K8 Triton GA-K8NSC-939 with the nForce3 250Gb chipset.  It uses BIOS version F5.  

The gentoo live cd gives this when free -m is run:

```

free -m

            total        used         free

Mem       487         65           418

-/+ buffers/cache   27           456

swap       0            0             0 

```

----------

## yaneurabeya

Regardless of what you may think, your AGP card may share memory with your system. Also, look out for 'shared memory' settings in your BIOS.

You still haven't told us what the amount of memory is that is on your video card.

----------

## oggialli

No, I think there are NO FX5200 cards that share memory. Correct me if I am wrong.

----------

## darker

The video card has 128MB of memory.  I find it hard to believe it would be sharing memory.

----------

## Denkino

 *darker wrote:*   

> 
> 
> The gentoo live cd gives this when free -m is run:
> 
> ```
> ...

 

I think this shows that there is NO ISSUE. your user-land memory will ALWAYS be 'some amount' less than your total physical memory... and that is.. OK (and exactly the way it is supposed to work).

Conky is working just fine, it is reporting exactly what the kernel is saying.

lets all just move on.

----------

## drphibes

the issue is that the 512Mb physical memory minus the 435Mb reported memory is unaccounted for.

----------

## darker

I just updated to the 2.6.14-gentoo-r5 kernel and reconfigured it as well.  The RAM number in conky now says 436M.  I do find it surprising that the kernel would take up so much memory.  Could there be other service that is taking up a lot of memory?

----------

## drphibes

i would double-check that the memory you purchased is ok; that it is compatible with your board; that it is installed correctly in the right DIMM slot; that your BIOS is up-to-date (I see F7 on their web site, two revs higher than the F5 you are using).   Then I would call Gigabyte and ask them directly for support.    If all that fails, I would return the motherboard.

----------

## widan

What does the BIOS report to the OS ? Sure it says 512MB on the POST screen, but it might report less to the OS (there can be reserved areas, ...). This would tell if it is a kernel problem (if BIOS memory map looks OK) or BIOS problem (if not all memory is reported to Linux). You can find the memory map at the beginning of dmesg, it looks like this:

```
BIOS-provided physical RAM map:

 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)

 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)

 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)

 BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)

 BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)

 BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)

 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)

 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)

 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)

127MB HIGHMEM available.

896MB LOWMEM available.
```

This tells you exactly how much physical RAM is available to the kernel (here 896MB+127MB=1023MB, so it is coherent with the 1GB RAM that is installed) and where unusable areas are. Then there is memory used for the kernel itself, so the actual memory seen by applications is a little less (1010MB here):

```
stephanie ~ # free -m

             total       used       free     shared    buffers     cached

Mem:          1010        985         25          0         52        469

-/+ buffers/cache:        462        547

Swap:          488          5        483
```

----------

## darker

I believe I have found the problem.  While looking through dmesg, I saw this:

```

Your BIOS doesn't have an aperature memory hole

Please enable the IOMMU option in the BIOS setup

This costs you 64MB RAM

mapping aperature over 65536KB of RAM @ 4000000

```

Unfortunately, I cannot find an IOMMU option in the BIOS setup.  I will update the BIOS tomorrow and see if it appears in the updated version.

----------

## darker

In the latest version of the BIOS.  The option still has not appeared.  After some googling I have determined that this particular Gigabyte motherboard does not support this feature.  Is there anything else I can do outside of the BIOS to fix this problem?

----------

## oggialli

I guess you are using x86_64 ? Try disabling IOMMU in kernel if you have it on (and enabling agpgart in char. devices).

----------

## darker

That seems to have worked.  Conky now displays 500M.  Thank you very much!!!

 :Very Happy: 

----------

## oggialli

Ah, great you got it fixed!

Yes, reading the logs is a good idea in almost any trouble  :Wink: 

----------

## dpetka2001

hello there i just saw this topic and got me to check my memory...i use 2 dimms of 512MB, so that gives us 1024MB in total...using ''free -m'' gives the following

```
free -m

             total       used       free     shared    buffers     cached

Mem:           883        784         98          0        130        457

-/+ buffers/cache:        195        687

Swap:         1027          0       1027
```

shouldn´t it say 1000MB instead?? could someone help me understand what is going on?? thanks in advance...

----------

## syg00

 *dpetka2001 wrote:*   

> ... could someone help me understand what is going on?? 

 Different issue entirely.

This gets raised almost daily.. Have a look at this article - note particularly the paragraph prior to subsection 2 heading.

----------

## dpetka2001

 *syg00 wrote:*   

> Different issue entirely.This gets raised almost daily.. Have a look at this article - note particularly the paragraph prior to subsection 2 heading.

 so you´re basically saying that it´s normal to have 883MB of memory since the kernel is using some aswell that will not ever be freed?? but what about someone referring to a patch that allows you to see the whole 1GB

```
Or you could apply the 1glowmem patch on your kernel and use the whole gig without highmem support
```

?? and someone else said that enabling HighMemory support got him to see more RAM than being this feature off...in extense of course of some exta CPU cycles...what would you suggest that i should do?? enable this feature in the kernel or maybe go with the patch?? and where could i find the patch in case i would like to experiment with it?? thanks...

----------

## syg00

Yes it's "normal" - for some value of normal.

Rather than hijack this thread, you should probably start another. The lomem patch will be in ck-sources I would think; along with others to comprise his patchset.

Can be obtained individually from Con's site.

----------

## drphibes

 *dpetka2001 wrote:*   

> hello there i just saw this topic and got me to check my memory...i use 2 dimms of 512MB, so that gives us 1024MB in total...using ''free -m'' gives the following
> 
> ```
> free -m
> 
> ...

 

You can get all of your memory by configuring your ordinary gentoo kernel with CONFIG_HIGHMEM4G=y.   You don't need patches or special kernels.

----------

## oggialli

Yes, true. Another option is 1GLOWMEM but that breaks many programs (most importantly valgrind which doesnt like the resulting vm split).

----------

