Bug 44384

Summary:	mem=XXX uses more memory than stated
Product:	[Retired] Red Hat Linux	Reporter:	Warren Jasper <wjasper>
Component:	kernel	Assignee:	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
Whiteboard:
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:	---	Target Upstream Version:
Embargoed:

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.