Bug 206111 - [PATCH][RHEL4U4] Fix estimate-mistake (e820-memory-hole and numnodes) of available_memory in x86_64
Summary: [PATCH][RHEL4U4] Fix estimate-mistake (e820-memory-hole and numnodes) of avai...
Keywords:
Status: CLOSED DUPLICATE of bug 206113
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.4
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Red Hat Kernel Manager
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-09-12 07:21 UTC by Masaki MAENO
Modified: 2007-11-17 01:14 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-12-04 22:42:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
numnodes patch (fix potential nodes to online nodes) - linux-2.6.9-numnodes.patch (502 bytes, patch)
2006-09-12 07:21 UTC, Masaki MAENO
no flags Details | Diff

Description Masaki MAENO 2006-09-12 07:21:07 UTC
Description of problem:
The available memory for which kernel can be used is misunderstood more than 
an actual amount in x86_64.
Therefore, it doesn't work correctly even if the kernel parameter such 
as dirty_ratio is set. 

Though "'[PATCH] Fix NUMA node sizing in nr_free_zone_pages (detail: 
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-
2.6.git;a=commitdiff;h=e310fd43256b3cf4d37f6447b8f7413ca744657a;hp=5fa918b451f62
5870cd4275ca908b2392ee86a51 )' and 'Fix node-info from ACPI'" was taken with 
RHEL4U4, the bug still exists.

Therefore, I offer two patches.
(1) numnodes patch
 It is corrected to use the number of potential nodes when memory setting is 
initialized in mm/page_alloc.c, kernel/sched.c and so on. (Correctness is the 
number of online nodes.)
 - I made a patch for RHEL4U4 that closed into x86_64 because the impact of 
Vanilla Kernel patches is too large.
    filename: linux-2.6.9-numnodes.patch

(2) e820 memory_holes patch
 It is corrected to misidentify memory_holes to available_memory by this patch.
 detail: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-
2.6.git;a=commit;h=485761bd6a72d33b3d4fa884927b2b0d983b701e
 - I had Vanilla Kernel patch fit RHEL4U4.
     filename: linux-2.6.13-e820.patch

I verified kernel-2.6.9-42.EL that applied these two patches, and passed. 
I strongly hope for the RHEL4U4-Update/RHEL4U5 adoption of this patch


Version-Release number of selected component (if applicable):
RHEL4U4: kernel-2.6.9-42.EL


Steps to Reproduce:
1. set vm.dirty_ratio={10 or 20 or 30, etc..}(const. dirty_background_ratio=10)
2. keep creating a lot of dirty pages 
   (example: 
       # dd if=/dev/zero of=/tmp/test01.bin & 
       # dd if=/dev/zero of=/tmp/test02.bin & ... [5 - 10 processes] )
3. keep doing output dirty-pages/total-pages(%) during execute (2)
   (example: Dirty/MemTotal x 100 in /proc/meminfo )

Actual results (Before applying the e820-holes/numnodes patches):
It doesn't become a value(= Dirty/MemTotal x 100) set to vm.dirty_ratio.  

# echo "20" > /proc/sys/vm/dirty_ratio
# ./output_dirty-memtotal.sh
# dd ... & x 10 
    ...
2006/09/12_14:57:42: 15
2006/09/12_14:57:43: 21
2006/09/12_14:57:44: 28
2006/09/12_14:57:46: 35
2006/09/12_14:57:47: 41
2006/09/12_14:57:48: 41
2006/09/12_14:57:49: 41
2006/09/12_14:57:50: 41
2006/09/12_14:57:51: 41
2006/09/12_14:57:52: 41
2006/09/12_14:57:53: 41
2006/09/12_14:57:54: 41
2006/09/12_14:57:55: 41
2006/09/12_14:57:56: 41
    ...
#

Expected results (After applying the e820-holes/numnodes patches):
It becomes a value(= Dirty/MemTotal x 100) set to vm.dirty_ratio.  

# echo "20" > /proc/sys/vm/dirty_ratio
# ./output_dirty-memtotal.sh
# dd ... & x 10 
    ...
2006/09/12_14:51:38: 0
2006/09/12_14:51:42: 12
2006/09/12_14:51:45: 15
2006/09/12_14:51:46: 15
2006/09/12_14:51:47: 17
2006/09/12_14:51:48: 17
2006/09/12_14:51:49: 18
2006/09/12_14:51:50: 18
2006/09/12_14:51:51: 20
2006/09/12_14:51:52: 20
2006/09/12_14:51:53: 20
2006/09/12_14:51:54: 20
2006/09/12_14:51:55: 20
2006/09/12_14:51:56: 20
    ...
#

Additional info:
By the way, the e820 memory_hole was very small (about 70MB) in my machine 
(=Actual/Expected results).
But, there is a machine that memory_hole is very large (about ?MB - ?GB), too.

- Before applying the patches (default kernel-2.6.9-42.EL):
# dmesg
    ...
On node 0 totalpages: 1048575                     <<<<<<<<<< memory_holes
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 1044479 pages, LIFO batch:16   
  HighMem zone: 0 pages, LIFO batch:1
On node 1 totalpages: 1048575
  DMA zone: 0 pages, LIFO batch:1
  Normal zone: 1048575 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
    ...
This costs you 64 MB of RAM
Mapping aperture over 65536 KB of RAM @ 4000000
Built 4 zonelists                                 <<<<<<<<<< numnodes
    ...

- After applying the patches (e820-holes/numnodes patched kernel-2.6.9-42.EL):
# dmesg
    ...
On node 0 totalpages: 1031946                     <<<<<<<<<< memory_holes
  DMA zone: 3994 pages, LIFO batch:1
  Normal zone: 1027952 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
On node 1 totalpages: 1048575
  DMA zone: 0 pages, LIFO batch:1
  Normal zone: 1048575 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
    ...
This costs you 64 MB of RAM
Mapping aperture over 65536 KB of RAM @ 4000000
Built 2 zonelists                                 <<<<<<<<<< numnodes
    ...

Comment 1 Masaki MAENO 2006-09-12 07:21:07 UTC
Created attachment 136053 [details]
numnodes patch (fix potential nodes to online nodes) - linux-2.6.9-numnodes.patch

Comment 2 Masaki MAENO 2006-09-12 07:51:46 UTC
#206111 duplicates with #206113, and erase #206111, please. 

Comment 3 Linda Wang 2006-12-04 22:42:39 UTC

*** This bug has been marked as a duplicate of 206113 ***


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