Bug 44384 - mem=XXX uses more memory than stated
Summary: mem=XXX uses more memory than stated
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-06-13 13:55 UTC by Warren Jasper
Modified: 2007-04-18 16:33 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-06-14 12:31:54 UTC
Embargoed:


Attachments (Terms of Use)

Description Warren Jasper 2001-06-13 13:55:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686)

Description of problem:
I am running 7.1 on a i686 box with 256 of memory.  When the system is
booted
normally, a cat /proc/iomem shows:
040ffc00-0fffffff : System RAM
which is correct.  However, if I set
mem=248M and reboot I get:
040ffc00-0f862bff : System RAM instead of 040ffc00 - 0f800000
if I try
mem=247M I get
0f0ffc00-0f762bff.

It appears that the kernel is reserving 0x62bff bytes of memory more that
what it was
told it has.

I am trying to reserve a large chunk of memory for DMA transfers, and I
need to write
a mmap method in my driver, so getting this EXACTLY right is important.  My
workaround was to set mem=247M  which freed up about 8.5 MB and just used
the top 8M.

How reproducible:
Always

Steps to Reproduce:
1.linux mem=248M
2.cat /proc/iomem
3.
	

Actual Results:  040ffc00-0f862bff  :  System RAM

Expected Results:  040ffc00 - 0f800000  : System RAM

Additional info:

Comment 1 Arjan van de Ven 2001-06-14 10:55:42 UTC
If you have a hole in the memory-map it seems the kernel accounts for that ;)
404479 bytes is quite believable as size of such hole (380kb in the lower 1Mb
region + bios reserved regions)

Comment 2 Warren Jasper 2001-06-14 12:31:49 UTC
Yes, that is exactly what is happening, but that is misleading.  If I put
mem=247M, I *thought*
I am saying that I only have 247M of memory.  The kernel is *using* 247M of
memory, but
because of the hole, it actually uses MORE.

{warrenj} cat /proc/iomem
00000000-0009f7ff : System RAM
0009f800-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000e0000-000effff : Extension ROM
000f0000-000fffff : System ROM
00100000-040fd7ff : System RAM
  00100000-002557df : Kernel code
  002557e0-0026c80b : Kernel data
040fd800-040ff7ff : ACPI Tables
040ff800-040ffbff : ACPI Non-volatile Storage
040ffc00-0f762bff : System RAM    <==================================
e4000000-e7ffffff : PCI device 1593:2041 (Bops Inc)
e8000000-ebffffff : PCI device 1593:2041 (Bops Inc)
ec000000-efffffff : PCI device 1593:2041 (Bops Inc)
f0000000-f3ffffff : PCI device 1593:2041 (Bops Inc)
f4000000-f4007fff : Yamaha Corporation YMF-740C [DS-1L Audio Controller]
f4008000-f4008fff : PCI device 100b:0020 (National Semiconductor Corporation)
  f4008000-f4008fff : eth0
f5000000-f5ffffff : PCI Bus #01
  f5000000-f5ffffff : nVidia Corporation Riva TnT2 [NV5]
f8000000-fbffffff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
fc000000-fdffffff : PCI Bus #01
  fc000000-fdffffff : nVidia Corporation Riva TnT2 [NV5]

If you don't put a mem= option, it ends at the memory boundary, so this
behaviour is not
consistant!


Comment 3 Arjan van de Ven 2001-06-14 12:46:44 UTC
I agree that this isn't consisitent behavior. Itw ill be fixed in the next
kernel we release.


Note You need to log in before you can comment on or make changes to this bug.