/proc/kcore size incorrect ?

/proc/kcore size incorrect ?

[J.A. Magallon]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

Hi all...

Probably this is a stupid question, but anyways...

I'm trying to make a script to generate an /etc/motd, and I wanted to
include memory size of the box.

I tried:

	echo $(($(stat -c %s /proc/kcore) / 1024 / 1024)) "Mb"

but it gives 1022 for a 1Gb box.

In fact:

	werewolf:~# ll /proc/kcore
	-r--------  1 root root 1072566272 2005.10.23 23:53 /proc/kcore
	werewolf:~# stat -c %s /proc/kcore
	1072566272

	werewolf:~# echo $((1024*1024*1024))
	1073741824

Why that difference ?

TIA

BTW, any simple method to get the real mem of the box ?

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.13-jam9 (gcc 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: /proc/kcore size incorrect ?

[Jon Masters]

On 10/23/05, J.A. Magallon <jamagallon@able.es> wrote:

> BTW, any simple method to get the real mem of the box ?

This is a typical example of using a hammer to crack a nut aka
modifying the kernel before giving up on userspace.

Several ways of looking up a solution:

    * google
    * man -k memory

Leading to:

* free(1):
    ``free  displays the total amount of free and used physical and swap''

* Or /proc/meminfo (both the same thing) - which you can trivially
parse using sed:

cat /proc/meminfo | sed -n -e "s/^MemTotal:[ ]*\([0-9]*\) kB\$/\1/p"

Jon.

Re: /proc/kcore size incorrect ?

[J.A. Magallon]

[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]

On Mon, 24 Oct 2005 00:13:44 +0100, Jon Masters <jonmasters@gmail.com> wrote:

> On 10/23/05, J.A. Magallon <jamagallon@able.es> wrote:
> 
> > BTW, any simple method to get the real mem of the box ?
> 
> This is a typical example of using a hammer to crack a nut aka
> modifying the kernel before giving up on userspace.
> 

Ejem.

Who talks about modifying anything ?

> Several ways of looking up a solution:
> 
>     * google

Well, perhaps I buy this, but as this looks like a strange/buggy thing, as
I will explain later...

>     * man -k memory
> 
> Leading to:
> 
> * free(1):
>     ``free  displays the total amount of free and used physical and swap''
> 
> * Or /proc/meminfo (both the same thing) - which you can trivially
> parse using sed:
> 
> cat /proc/meminfo | sed -n -e "s/^MemTotal:[ ]*\([0-9]*\) kB\$/\1/p"
> 

Do your homework.

free gives the free amount of memory _available for the user_, ie, the
full memory of the box minus the kernel reserved part.

From dmesg:

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003fee0000 (usable)
 BIOS-e820: 000000003fee0000 - 000000003fee3000 (ACPI NVS)
 BIOS-e820: 000000003fee3000 - 000000003fef0000 (ACPI data)
 BIOS-e820: 000000003fef0000 - 000000003ff00000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
1022MB LOWMEM available.
...
Memory: 1034744k/1047424k available (1858k kernel code, 12208k reserved, 634k da
ta, 184k init, 0k highmem)
werewolf:~> echo $((1047424 / 1024))
1022

werewolf:~> free
             total       used       free     shared    buffers     cached
Mem:       1035012    1000660      34352          0      98348     649284
werewolf:~> cat /proc/meminfo | grep MemTotal
MemTotal:      1035012 kB
werewolf:~> echo $((1035012 / 1024))
1010

So free/proc give the available memory, not the total:
- free: 1010 Mb
- kcore: 1022 Mb

I expected /proc/kcore to give the size of your installed memory, with
the reserved BIOS areas just not accesible, but it looks like it already
has them discounted, so gives 1022 Mb.

It looks really silly to have a motd say "wellcome to this box, it has
2 xeons and 1022 Mb of RAM".



--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.13-jam9 (gcc 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: /proc/kcore size incorrect ?

[Jon Masters]

On 10/24/05, J.A. Magallon <jamagallon@able.es> wrote:
> On Mon, 24 Oct 2005 00:13:44 +0100, Jon Masters <jonmasters@gmail.com> wrote:
>
> > On 10/23/05, J.A. Magallon <jamagallon@able.es> wrote:
> >
> > > BTW, any simple method to get the real mem of the box ?
> >
> > This is a typical example of using a hammer to crack a nut aka
> > modifying the kernel before giving up on userspace.

> Who talks about modifying anything ?

Your message implied that /proc/kcore needed "fixing" for your
particular application. Perhaps I missunderstood though.

> >     * man -k memory
> >
> > Leading to:
> >
> > * free(1):
> >     ``free  displays the total amount of free and used physical and swap''
> >
> > * Or /proc/meminfo (both the same thing) - which you can trivially
> > parse using sed:
> >
> > cat /proc/meminfo | sed -n -e "s/^MemTotal:[ ]*\([0-9]*\) kB\$/\1/p"

> Do your homework.

I did, thanks!

> free gives the free amount of memory _available for the user_, ie, the
> full memory of the box minus the kernel reserved part.

If you can't use the memory, what's the point in reporting it? If
you're really bothered, parse the dmesg output.

> It looks really silly to have a motd say "wellcome to this box, it has
> 2 xeons and 1022 Mb of RAM".

Yes it does. Showing off specs like that (and in your signature) went
out of fashion a while ago :-)

Jon.

Re: /proc/kcore size incorrect ?

[Stefan Smietanowski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.

> I expected /proc/kcore to give the size of your installed memory, with
> the reserved BIOS areas just not accesible, but it looks like it already
> has them discounted, so gives 1022 Mb.
> 
> It looks really silly to have a motd say "wellcome to this box, it has
> 2 xeons and 1022 Mb of RAM".

Then round it on 32MiB boundary? 128MiB boundary?

I did something else that "needed" the size of the memory installed
and that's how I did.

( I have an install script which I run at the end of an installation
  of a system that does a lot of stuff the distro doesn't and one
  of the things it does is simply to take the size of the memory
  rounded up, multiply by 2 and then create a swapfile in a specified
  location. )

// Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFDXO1+Brn2kJu9P78RAp6aAJ9VXDLkwGHkewZtyIsajlcMugsuUwCdHKB6
da0LD9u6SHA4iL/OfHr6dD8=
=3DXl
-----END PGP SIGNATURE-----

Re: /proc/kcore size incorrect ?

[Matan Peled]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

J.A. Magallon wrote:
> I expected /proc/kcore to give the size of your installed memory, with
> the reserved BIOS areas just not accesible, but it looks like it already
> has them discounted, so gives 1022 Mb.
> 
> It looks really silly to have a motd say "wellcome to this box, it has
> 2 xeons and 1022 Mb of RAM".

I don't know why, but 'du' seems to be doing a better job.

chaosite@kaitou ~ $ du /proc/kcore --block-size=1M
1024	/proc/kcore
chaosite@kaitou ~ $ echo $(($(stat -c %s /proc/kcore) / 1024 / 1024))
1023

- --
[Name      ]   ::  [Matan I. Peled    ]
[Location  ]   ::  [Israel            ]
[Public Key]   ::  [0xD6F42CA5        ]
[Keyserver ]   ::  [keyserver.kjsl.com]
encrypted/signed  plain text  preferred

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDXh82A7Qvptb0LKURApoUAKCVpGY9BlyD2SwN1aPy566ptf5DGwCdExco
emsyr109/L8ls6Czh7mv45Q=
=jRrP
-----END PGP SIGNATURE-----

Re: /proc/kcore size incorrect ?

[Brian Waite]

On Tuesday 25 October 2005 8:04 am, Matan Peled wrote:
> J.A. Magallon wrote:
> > I expected /proc/kcore to give the size of your installed memory, with
> > the reserved BIOS areas just not accesible, but it looks like it already
> > has them discounted, so gives 1022 Mb.
> >
> > It looks really silly to have a motd say "wellcome to this box, it has
> > 2 xeons and 1022 Mb of RAM".
>
> I don't know why, but 'du' seems to be doing a better job.
>
> chaosite@kaitou ~ $ du /proc/kcore --block-size=1M
> 1024	/proc/kcore
> chaosite@kaitou ~ $ echo $(($(stat -c %s /proc/kcore) / 1024 / 1024))
> 1023
To show just how fragile your tests are, here is what my laptop reports with 1 
GB memory:

bwaite@ronzoni:~> uname -a
Linux ronzoni 2.6.11.4-21.9-default #1 Fri Aug 19 11:58:59 UTC 2005 i686 i686 
i386 GNU/Linux
bwaite@ronzoni:~> du /proc/kcore --block-size=1M
897     /proc/kcore

bwaite@ronzoni:~> echo $(($(stat -c %s /proc/kcore) / 1024 / 1024))
896

bwaite@ronzoni:~> dmesg | grep MEM
127MB HIGHMEM available.
896MB LOWMEM available.

bwaite@ronzoni:~> dmesg | grep Memory:
Memory: 1033684k/1048248k available (1866k kernel code, 13796k reserved, 658k 
data, 204k init, 130744k highmem)

In short why not use free and show what your users can use. Otherwise, just 
make a static motd and change it whenever you change memory configurations. I 
can't believe you are changing that often. If you are going to go overboard 
and write a script just start doing the round up on your own.

Thanks
Brian

Re: /proc/kcore size incorrect ? (OT)

[Eric Piel]

J.A. Magallon wrote:
:
> 
> It looks really silly to have a motd say "wellcome to this box, it has
> 2 xeons and 1022 Mb of RAM".
Ok, everyone seems to go with his idea on this thread so I'd like to 
share mine too :-P

If you want to know how much _physical_ memory there is on your 
computer, then a good way would be too use dmidecode. The parsing might 
require more work than a "du" but you will never have trouble with 
rounding...

Eric

Re: /proc/kcore size incorrect ? (OT)

[J.A. Magallon]

On 2005.10.25, at 18:02, Eric Piel wrote:

> J.A. Magallon wrote:
> :
>
>> It looks really silly to have a motd say "wellcome to this box, it  
>> has
>> 2 xeons and 1022 Mb of RAM".
>>
> Ok, everyone seems to go with his idea on this thread so I'd like  
> to share mine too :-P
>
> If you want to know how much _physical_ memory there is on your  
> computer, then a good way would be too use dmidecode. The parsing  
> might require more work than a "du" but you will never have trouble  
> with rounding...
>

Yes, I know...

If you remember, the question about 'how to guess this box mem' was
under something like "BTW ...", kinda collateral.

My concerns were about if the size of /proc/kcore should be what it is
now, and why...

--
J.A. Magallon <jamagallon()able!es>   \          Software is like sex:
wolverine                              \    It's better when it's free
MacOS X 10.4.2, Darwin Kernel Version 8.2.0

Re: /proc/kcore size incorrect ? (OT)

[Tony Luck]

> My concerns were about if the size of /proc/kcore should be what it is
> now, and why...

/proc/kcore is an ELF format file (try using objdump(1) to read
headers from it).

The data within the file may be sparse (especially on discontig
and NUMA systems).  So the size just represents the end of
the highest addressed memory section.  E.g. on my desktop:

$ ls -l /proc/kcore
-r--------  1 root root 4611686019496083456 Oct 25 09:52 /proc/kcore

-Tony