lkml.org 
[lkml]   [1998]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.036 / U:1.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site