Hello, there!

currently, my 32 bit unix workstation has 4G memory
but my program can only use 2G memory. when I have used about 2G
memory,
I cannot allocate more.

is there a way to use >2G virtual address space in 32 bit unix?

any suggests are highly appreciated!

[ Post a follow-up to this message ]

bohu.seattle@gmail.com wrote On 04/18/07 13:11,:
> Hello, there!
>
>    currently, my 32 bit unix workstation has 4G memory
> but my program can only use 2G memory. when I have used about 2G
> memory,
> I cannot allocate more.
>
>    is there a way to use >2G virtual address space in 32 bit unix?
>
> any suggests are highly appreciated!
>

http://www.opensolaris.org/

(Disclaimer: I work for Sun, but don't speak for Sun.)

--
Eric.Sosman@sun.com

[ Post a follow-up to this message ]

bohu.seattle@gmail.com wrote:
>    currently, my 32 bit unix workstation has 4G memory
> but my program can only use 2G memory. when I have used about 2G
> memory,
> I cannot allocate more.
>
>    is there a way to use >2G virtual address space in 32 bit unix?

With linux you normally have a 1G/3G split, but there is the 4G/4G patch
where the kernel runs in a separate memory space, thus allowing 4GB per
userspace process at some penalty to context switching overhead.

If you want more than 4GB you will have to start doing funky things like
mapping/unmapping files manually.

Chris

[ Post a follow-up to this message ]

> If you want more than 4GB you will have to start doing funky things like
> mapping/unmapping files manually.
Yup, that sounds familiar to me.
What I did in the case where I had to do this was to have some scheme
in which each file could be uniquely identified. Fortunately, there
were cases where files would go "out of scope"(to abuse the terminology
slightly) and I could unmap a set of files and then, later, map a new
set. mapping/unmapping did have some performance implications. No data
on this but it certainly makes intuitive sense that frequent
mapping/unmapping of files will be problematic, no? ;)

[ Post a follow-up to this message ]

Chris Friesen <cbf123@mail.usask.ca> writes:
> bohu.seattle@gmail.com wrote: 
>
> With linux you normally have a 1G/3G split, but there is the 4G/4G
> patch where the kernel runs in a separate memory space, thus allowing
> 4GB per userspace process at some penalty to context switching
> overhead.

This isn't quite true. If the kernel is mapped into each processes
address space, a system call just needs to trap into the kernel
somehow, with cache and TLB contents (insofar applicable) just remaining
valid. Otherwise, parts or all of both needs to be flushed.

The difference is roughly the same as the difference between
context-switching among threads that are part of the same process and
context-switching between independent processes.

[ Post a follow-up to this message ]