Messages in this thread | | | Date | Mon, 5 Jan 1998 16:28:57 -0800 | From | "David S. Miller" <> | Subject | Re: task_struct offsets broken in 2.1.77 |
| |
Date: Tue, 6 Jan 1998 01:14:39 +0100 (CET) From: MOLNAR Ingo <mingo@chiara.csoma.elte.hu>
it was put there on purpose in the original patch (which you greatly improved, leaving almost nothing untouched, except that big fat bug ;), my thinking was that we access the first cacheline of the task struct when we enter the system, and this is the time when access checks are done as well, so the cacheline will be hot. Is there any other ordering logic behind that stuff? Also, as debug[8] is exactly 1 cacheline, we could align it on cacheline as well, it gets active only at context switch time, a few orders less used than the system entry code.
Jakub has a great interest in doing the task_struct reorganization. He has asked most of the port maintainers to give him a good idea of what the important elements are for a particular port.
My guess is that it will be best to have something like:
struct task_struct { ... generic stuff which get touched by all code paths ... struct thread_struct tss; ... non-hot generic things which remain ... };
There is also another issue of making the copies of the task struct at fork/clone time faster. Many things are copied unnecessarily, since in the child they are always set to new values after the copy. We had a small hack in the CVS sources to do this just for the FPU stuff in the thread_struct on sparc64 and this made for a sickeningly large performance boost for fork/exit overhead... just imagine if we did it right...
Later, David S. Miller davem@dm.cobaltmicro.com
| |