On Thu, 13 Feb 2003, Dan Kegel wrote:

> Man Chi Ly wrote:
> >>>Physical memory, maybe, but I bet you a nickel you got
> >>>up near 1GB of *virtual* memory.  Go learn about how
> >>>thread stacks work.  You're not running out of RAM; you're
> >>>running out of address space.
> >>
> >>I guess I don't know enough about the internals of the memory management, but how? 
> I know
> >>that virtual address is given by the operating system, which uses the virtual 
>addresses to
> >>map to physical addresses so it can do swapping, but why would it run out of 
>address?
> 
> Virtual addresses aren't really given by the OS.  Well, kinda.
> The OS says something like "each app will have the addresses from 0 to N-1"
> where N is either 1 gigabyte, 2 gigabytes, or 3 gigabytes, depending
> on how the kernel is configured.  (Or something like that.  Different
> operating systems do things slightly differently.)
> All that space is virtual until the app stores something at those
> addresses.   So far so good, right?  Now, when the app creates a new
> thread, it is assigned a fixed chunk of address space for its stack.
> It has to be of a fixed size and at a fixed location for technical
> reasons, but most of it can remain virtual.  Problem is, if all you
> have is 1 gigabyte of address space, and you've picked a stack per thread
> of 100KB, the max number of thread stacks that can fit is 1 gigabyte / 100 KB
> = 10,000.  See?

I was under the impression that since linux made ever thread a seperate 
process they each had their own stack and only shared the heap memory.
> 
> $ grep CONFIG_.GB /boot/config-2.4.18-14
> # CONFIG_3GB is not set
> # CONFIG_2GB is not set
> CONFIG_1GB=y

So I just have to set that line in /boot/config-2.4.18-14 and reboot?  Is 
that limit per process or system wide?  Can you point me at documentation 
for the config options?
> 
> 


----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to