If you have some data which is common to a group of threads/processes,
it could be stored in one (or more--redundantly) of the process stacks.
If the refcount is not zero and the process stack holding the data is
to die, the data can be moved to another stack or otherwise stored
somewhere else.
>
> Thus, it'd be interesting to collapse all the common stuff in
> the task_struct corresponding to a same thread group into a single
> one, and move whatever is thread specific out to a thread-specific
> structure [alike to thread_info, although I guess you want to keep
> thread_info really small for cache performance].
>
> That should save a lot of task_structs when threading and move all
> the info to that place you say. It is going to be a lot of work,
> though, very kind of 2.7.
>
It might, nevertheless, be a good an equitable solution to the problem.
Another way to skin a cat, as it were.
>
>>Someone complained about a process structure already being too bloated.
>> Unless it's several K in size already, you can bloat it up all you
>>please this way.
>
>
> 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? :)
>
>>Another advantage is that you could make the datastructures growable.
>>The stack grows down, and the data grows up. As long as they don't
>>meet, all is well.
>
>
> 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.
-
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/