Re: 2.6.6-rc3-mm2 (4KSTACK)

[Jörn Engel]

On Fri, 7 May 2004 11:11:30 -0500, Steve Lord wrote:
> 
> That was not really my point, consider any memory allocation on the
> stack which is being replaced with an allocate to save space. Then replace
> the saved stack space with the potential stack space used to
> free memory by writing it out via a filesystem. You cannot make all
> the allocations in the kernel GFP_NOFS.
> 
> Now at least if the memory is allocated high enough up in the
> call chain it fixes the problems of a function with a large
> stack frame with a deep stack underneath it. It does not fix
> anything if the function is already deep in the stack.
> 
> All this is doing is papering over the cracks.

No, it turns two problems into one.  We have the problem you describe
anyway, there is no point avoiding it here.  It remains unsolved, but
that's just one problem left, not two.

Would it make sense to switch stacks if memory allocation has to free
other memory first?  Sounds a bit insane, but that problem needs a
solution as well.

Jörn

-- 
...one more straw can't possibly matter...
-- Kirby Bakken
-
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/