Shrinking stack

Shrinking stack

[Stelios Xanthakis]

Hi,

Consider this feature (I personally need very much:).

The stack of a process only expands, yes?
It is possible to release part of the unused stack by munmap() if we
know the start of the stack vma area.

Why is this interesting:

A classic question in C programming is, should we use the stack for
allocating temporary space? With the current implementation the following
code is bad:

void init ()
{
	int tmp [100000];
	....
}

The stack space will remain at 400kB even if the rest of the program only
needs up to 10kB. (I have a patch to view the unused stack through /proc)

Now the above code example is extreme but before a big project is started
we'll have to choose whether we will use malloc() or alloca() for
temporary space. alloca() is fast and efficient but with the
stack-only-expands policy (which is ok since stack usage occurs in
bursts and the kernel doesn't know when to release unused stack), it is
very possible to end up with lots of stack most of which is unused.

I can provide some examples of very-interesting code with alloca() which
is better in all aspects than a malloc() version (speed, fragmentation,
code size). In the case an entire program's functions are based on
alloca() we do indeed suffer from the "unused stack syndrome" though.

I've implemented a patch where the kernel provides the vma->vm_start of
the stack area through prctl() syscall. Its very simple and adds very
little to the kernel code.
Once this call exists in the kernel and application may declare:
-----------stackfix.h-------------
#include <linux/prctl.h>
#include <asm/page.h>

#ifdef PR_GET_STKBOTTOM		/* We have get_stack_bottom */

#define PAGE_ALIGN(x) ((x) & PAGE_MASK) /* Downwards alignment for esp */

#define STACKFIX {\
	unsigned long sb, esp, len;\
	prctl (PR_GET_STKBOTTOM, (unsigned long)&sb, 0, 0, 0);\
	__asm__ ("mov %%esp,%0"::"m"(esp));\
	len = (sb < PAGE_ALIGN(esp)) ? PAGE_ALIGN(esp)-sb : 0;\
	if (len) munmap ((void*)sb, len);\
	}

#else				/* system doesn't have get_stack_bottom */

#define STACKFIX ;

#endif
--------------------------------

Whenever STACKFIX is called from a program is will reduce the unused stack
to < PAGE_SIZE.
We can then apply STACKFIX on important program locations. For example
applications as we know usually spend a lot of time blocked on parts that
get/send external things (select(),ipc..).

void client()		/* Our true `main' */
{
	while (1) {
		fgets (/*Get a request from the client*/);
		do_calculations();
		STACKFIX        <-----------------Good Place
	}
}


It probably seems obsolete, but one feels different after heavy alloca()
usage.

I'd be interested to discuss in depth the stack vs. dataseg allocations
for temporary space.


Regards

Stelios
<axanth@tee.gr>




--
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/

Re: Shrinking stack

[Kanoj Sarcar]

> 
> The stack space will remain at 400kB even if the rest of the program only
> needs up to 10kB. (I have a patch to view the unused stack through /proc)

Only if you ever touch the stack page, will it be allocated. Else, no
physical page is associated. And if the kernel runs low on memory, it
will reclaim rarely accessed pages.

> I've implemented a patch where the kernel provides the vma->vm_start of
> the stack area through prctl() syscall. Its very simple and adds very
> little to the kernel code.

I believe there is only one foolproof method of determing the stack.
And that is by looking at the user's esp. (Programs probably might
have multiple stack segments, maybe even switch between them by  
modifying esp ... in extreme cases. Not sure how pthreads work in 
this respect.) 

Thus, instead of having the kernel do this, you can do this in
userland by getting /proc/pid/maps, then identifying the vma that
contains the current value of esp. (To get the esp, you can either 
write processor specific code, or maybe get the address of a variable
on stack). 

Kanoj
--
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/