From: David Pinedo <dp@fc.hp.com>
To: linux-mm@kvack.org
Subject: Re: Running out of vmalloc space
Date: Tue, 22 May 2001 17:15:26 -0600 [thread overview]
Message-ID: <3B0AF30D.8D25806A@fc.hp.com> (raw)
In-Reply-To: 3B045546.312BA42E@fc.hp.com
I followed up on the suggestion of several folks to not map the graphics
board into kernel vm space. While investigating how to do that, I
discovered that the frame buffer space did not need to be mapped -- it
was already being mapped with the control space. So instead of needing
(32M+16M)*2=96M of vmalloc space, I only need 32M*2=64M. That change
seemed easier than figuring out how not to map the board into kernel vm
space, so...
Given that VMALLOC_RESERVE is 128M, and there was about 92M left when my
graphics driver was being initialized, I thought I should have plenty of
room to map the two graphics boards. It worked -- the first time. If I
exitted the X server and restarted it, I would get the same errors from
the X server as when it was not able to map one of the devices.
I verified that the kernel vm space was being freed when the X server is
shut down, so that wasn't the problem. On further investigation, I found
that after the X server initialized the graphics boards, somebody else
was allocating a 24k chunk of vm space, immiediately after the two
chunks allocated by the graphics driver. When the graphics driver tried
to re-allocate those two chunks the next time the X server was started,
it was able to get the first, but not the second chunk. I looked at the
get_vm_area code in vmalloc.c, I found that it will not allow a vm space
to be allocated from a free space that is exactly the size of the space
being allocated. I think the statement:
if (size + addr < (unsigned long) tmp->addr)
break;
should be:
if (size + addr <= (unsigned long) tmp->addr)
break;
Making this change seems to fix my problem. :-)
David Pinedo
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2001-05-22 23:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-17 17:13 Running out of vmalloc space David Pinedo
2001-05-17 17:39 ` Stephen C. Tweedie
2001-05-17 22:48 ` David Pinedo
2001-05-18 11:24 ` Andi Kleen
2001-05-18 11:53 ` Stephen C. Tweedie
2001-05-18 16:44 ` Christoph Hellwig
2001-05-22 23:15 ` David Pinedo [this message]
2001-05-23 9:35 ` Stephen C. Tweedie
2001-05-23 16:14 ` David Pinedo
2001-05-23 16:45 ` Stephen C. Tweedie
2001-05-26 5:13 ` Andrew Morton
2001-05-17 19:16 ` Matti Aarnio
2001-05-17 19:23 ` Christoph Hellwig
2001-05-17 20:10 ` Matti Aarnio
-- strict thread matches above, loose matches on Subject: below --
2001-05-17 18:51 Hua Ji
2001-05-17 20:17 ` Andi Kleen
2001-05-17 21:58 Hua Ji
2001-05-18 8:21 ` Matti Aarnio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B0AF30D.8D25806A@fc.hp.com \
--to=dp@fc.hp.com \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.