I don't think you need that redundancy - at the end of the day, it
is much simpler to just have the common task struct (could we say,
process?) with the shared stuff - replication is nice, but not in
> > Not really - the more bloated, the more cache misses you will have.
> > There are a lot of fields that don't use all the bits and a lot
> > of Booleans; it'd make sense to collapse all those into a single
> > word if possible.
> Most assuredly. Why are they not already? :)
Beats me ... maybe there are performance concerns I am not aware
of, or simply, it has not been tackled. This is something I have
on my list of "would be interesting to work on".
> > To solve that, you put the structures on the top of the area instead
> > of at the beginning. That way you are sure the stack cannot overflow
> > over your (very delicate) data structures, and makes it easier to add
> > an overflow guard page (as the stack end is at the beginning of a
> > page).
> I believe I mentioned that idea. Either the stack and data grow in
> opposite directions, with obvious advantages and risks, or the data is
> at the top of the area but therefore not growable.
Kill me ... my apologies; sometimes it seems that I don't master
reading as much as I thought :]
Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/