> > Our memory bloat is already pretty gross in 2.4 without adding 16K task
> > stacks to the oversided struct page, bootmem and excess double linked lists.
>
> There are some people who think that the 5kB stack we have now is too
> small ;(
Yes but we dont want to let them win or next year 16K will be too small and
then they'll want to 16K C++ stack objects. At the very least we should
make them have to use
really_slow_vmalloc_and_switch_to_big_temporary_stack()
really_slow_vfree_and_return_to_old_stack()
_and_ make them type function names that long.
Granted its less of an issue in 2.5 because we can afford to finally make
DMA off the stack a crime (right now its an offence but one that is violated
in too many places to be sure of killing them all off) - scsi for one does
it.
> That should work fairly well, and has the advantage that you can hide more
> state there if you want (ie it allows us, on demand, to move hot state of
> "struct task_struct" up there).
Sweet. Now that I'd completely missed. Task private state and task
public state splitting
> So it would basically be a small per-CPU/thread area, not just the "struct
> task_struct".
Yep
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Nov 07 2001 - 21:00:31 EST