Re: Huge contiguous memory allocation in userspace

["Joseph A. Knapka" <jknapka@earthlink.net>]

You might also consider building a kernel with an increased value
for PAGE_OFFSET. That will make more room for userspace virtual
mappings. Of course, you need to let the kernel have a significant
amount of virtual space between PAGE_OFFSET and 4GB, but I'd think
(haven't tried it) that you could move PAGE_OFFSET up to 3.5GB or
so. I don't think you can go much past 3.5GB without running into
problems, though, since most kernel data needs to be allocated in
the direct-mapped area, not in HIGHMEM pages.

-- Joe

"Joseph P. Garcia" wrote:
> 
> On Wednesday 24 January 2001 16:51, you wrote:
> > Hi, Joseph,
> >
> > Does the allocation succeed, and you get a segfault when trying to
> > access
> > the allocated memory? Or does the allocation just fail?
> >
> > I don't know for sure what the cause of your problem is, but remember
> > that the virtual address space for user processes only extends from 0 to
> > PAGE_OFFSET, which is typically 3GB, so getting at any more real RAM
> > than
> > that is probably not possible. Also, in order to allocate a virtual
> > region
> > the kernel must be able to find a contiguous block of virtual space
> > large
> > enough to accommodate the request, so possibly virtual-space
> > fragmentation is
> > the cause of your trouble. In that case I would expect the malloc() call
> > to just fail.
> >
> > You could get an authoritative answer by posting to the linux-mm list
> > (linux-mm@kvack.org).
> >
> > HTH,
> >
> > -- Joe
> 
> The allocation fails, though the fortran seems to allocate as much as it can
> and succeed anyway.  I was thinking it was virtual fragmentation.  Given that
> virtual memory was partially created to handle physical fragmentation, I'd
> hoped there would be some way to clean up any virtual fragmentation.
> 
> I just spent some time on this with a member from another group in the
> building with the same issues.  We are thinking that there could be a
> signed/unsigned conflict.  Possibly fixed in glibc2.2, which could be why the
> URL I listed earlier said that it's needed to access beyond 2G.  The Portland
> compiler links to glibc 2.0 (source: 'nm' to a created binary) and we were
> thinking of writing our own malloc/calloc/realloc/free and see if we could
> swap that in to see if that shows conflicted in signed-ness.
> 
> Thanks for your response.
> 
> --
> Joseph P. Garcia
> Programmer - UW Lidar Group
> http://lidar.ssec.wisc.edu/

-- Joe Knapka
-
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/
IRC Channel:   irc.openprojects.net / #kernelnewbies
Web Page:      http://www.surriel.com/kernelnewbies.shtml