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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
