Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?

From: Rene Herman
Date: Sat Jul 14 2007 - 18:20:25 EST


On 07/14/2007 09:17 PM, Matt Mackall wrote:

On Fri, Jul 13, 2007 at 03:20:54PM +0200, Rene Herman wrote:

As far as I'm aware, the actual reason for 4K stacks is that after the system has been up and running for some time getting "1 physically contiguous pages" becomes significantly easier than 2 which wouldn't be arbitrary.

If there are exactly two free pages in the system, the odds of them
being buddies (ie adjacent AND properly aligned) is quite small. The
available page pool has to grow quite a bit before the availability of
order-1 page pairs approaches 100%.

So if we fail to allocate an 8k stack when we could have allocated a
4k stack, we're almost certainly failing significantly prematurely.

Quite. Ofcourse, saying "our stacks are 1 page" would be the by far easiest solution to that. Personally, I've been running with 4K stacks exclusively on a variety of machines for quite some time now, but I can't say I'm all too adventurous with respect to filesystems (especially) so I'm not sure how many problems remain with 4K stacks. I did recently see Andrew Morton say that problems _do_ still exist. If it's just XFS -- well, heck...

Moreover though, rather than 4K, the issue is "single page" stacks meaning a larger (soft-) pagesize would seem to fix things nicely. I've been reading about that on this list off and on for some time -- no idea where that stands though.

As I've pointed out before, it's fairly easy to make our stack
growable with a trampoline in the troublesome paths. Something like:

int growstack(int headroom, int func, void *data)
{
void *new_stack;
int ret;

if (likely(available_stack() > headroom))
return func(data);

#ifdef CONFIG_GROWSTACK_STATS
/* gather statistics about stack-heavy paths */
#endif
/* warn/abort if we're recursing too deeply */

new_stack = get_free_page();
switch_to_new_stack(new_stack);
ret = func(data);
cleanup_stack(new_stack);
return ret;
}

This would also need something to tell func() where its current_thread_info is now at. Which might not be much of a problem. Can't think of much else either but it's the kind of thing you'd _like_ to be a problem just to have an excuse to shoot down an icky notion like that...

Would you intend this just as a "make this path work until we fix it properly" kind of thing?

Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/