Bug 44384

Summary: mem=XXX uses more memory than stated
Product: [Retired] Red Hat Linux Reporter: Warren Jasper <wjasper>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: low Docs Contact:
Priority: medium    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-06-14 12:31:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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
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

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:

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

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

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.