Bug 173193 - vmalloc limited to 64Mb
Summary: vmalloc limited to 64Mb
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Larry Woodman
QA Contact: Brian Brock
URL:
Whiteboard:
: 179098 (view as bug list)
Depends On:
Blocks: 181409
TreeView+ depends on / blocked
 
Reported: 2005-11-14 21:07 UTC by Jean Blouin
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version: RHSA-2006-0575
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-10 21:31:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2006:0575 0 normal SHIPPED_LIVE Important: Updated kernel packages available for Red Hat Enterprise Linux 4 Update 4 2006-08-10 04:00:00 UTC

Description Jean Blouin 2005-11-14 21:07:35 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050719 Red Hat/1.0.6-1.4.1 Firefox/1.0.6

Description of problem:
On a 64 bit system with large amount of ram the vmalloc one can allocate should not be limited to 64Mb. A patch for this bug is already submited for the kernel 2.6.11 can this patch be back ported to 2.6.9?

Here is a quote and the patch from Andi Kleen on the LKML

The vmap vmalloc rework in 2.5 had a unintended side effect.
vmalloc uses kmalloc now to allocate an array with a list of pages.
kmalloc has a 128K maximum. This limits the vmalloc maximum size
to 64MB on a 64bit system with 4K pages. That limit causes problems
with other subsystems, e.g. iptables relies on allocating large
vmallocs for its rule sets.

This is a bug IMHO - on 64bit platforms there shouldn't be
such a low limit on the vmalloc size. And even on 32bit it's too
small for custom kernels with enlarged vmalloc area.

Another problem is that this makes vmalloc unreliable. After the
system has been running for some time it is unlikely that kmalloc
will be able to allocate >order 2 pages due to memory fragmentation.

This patch takes the easy way out for fixing this by just allocating
this array with vmalloc when it is larger than a page.
While more complicated and intrusive solutions would be possible
they didn't use vmalloc recursively they didn't seem it worth
to handle this very infrequent case.

Please note that the vmalloc recursion is strictly bounded
because each nested allocation will generate a much smaller
stack frame. Also the kernel stack can handle even a few
recursion steps easily because vmalloc has only a small
stack frame.

Signed-off-by: Andi Kleen <ak@xxxxxxx>

diff -u linux-2.6.11rc3/mm/vmalloc.c-o linux-2.6.11rc3/mm/vmalloc.c
--- linux-2.6.11rc3/mm/vmalloc.c-o 2005-02-04 09:13:51.000000000 +0100
+++ linux-2.6.11rc3/mm/vmalloc.c 2005-02-08 10:59:58.000000000 +0100
@@ -378,7 +378,10 @@
__free_page(area->pages[i]);
}

- kfree(area->pages);
+ if (area->nr_pages > PAGE_SIZE/sizeof(struct page *))
+ vfree(area->pages);
+ else
+ kfree(area->pages);
}

kfree(area);
@@ -482,7 +485,12 @@
array_size = (nr_pages * sizeof(struct page *));

area->nr_pages = nr_pages;
- area->pages = pages = kmalloc(array_size, (gfp_mask & ~__GFP_HIGHMEM));
+ /* Please note that the recursion is strictly bounded. */
+ if (array_size > PAGE_SIZE)
+ pages = __vmalloc(array_size, gfp_mask, PAGE_KERNEL);
+ else
+ pages = kmalloc(array_size, (gfp_mask & ~__GFP_HIGHMEM));
+ area->pages = pages;
if (!area->pages) {
remove_vm_area(area->addr);
kfree(area);
-

 

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

How reproducible:
Always

Steps to Reproduce:
1.try to allocate more than 64Mb of vmalloc 
2.
3.
  

Actual Results:  the allocation fails

Expected Results:  allocation succeed

Additional info:

Comment 1 Larry Woodman 2006-02-08 18:35:02 UTC
I submitted the patch to fix this in RHEL4 but it was too late for U3 so it has
been postponed to RHEL4-U4.

Larry Woodman


Comment 2 Jason Baron 2006-03-16 18:45:14 UTC
just curious, did you hit this in practice, or its just a theoretical problem?

Comment 3 Jean Blouin 2006-03-16 18:57:25 UTC
Yes, we hit this in practice, we have a driver for an optimized file system
which can allocates up the 512 Mb of vmalloc for huge disk arrays.


Comment 4 Jason Baron 2006-03-17 16:38:49 UTC
committed in stream U4 build 34.4. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/

Comment 8 Red Hat Bugzilla 2006-08-10 21:31:53 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2006-0575.html


Comment 9 Larry Woodman 2007-07-10 19:28:50 UTC
*** Bug 179098 has been marked as a duplicate of this bug. ***


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