Let me give a more thorough example to make this more clear. Let's say
we have the following macros:
#define __current_virt_addr 0x01234567
#define current ((struct *task_struct)%esp & ~8191)
#define __current ((struct *task_struct)__current_virt_addr)
Ok, now the current task is mapped at two addresses in the kernel
given by current and __current. The following holds:
current != __current
current->mm == __current->mm
current->fs == __current->fs etc.
Now, if we're interested in getting say the pid of the currently
running process, it is perfectly safe to say:
my_pid = __current->pid;
which is faster than what we currently do in 2.1, which is equivalent
to
my_pid = current->pid;
For most accesses to current, we are not interested in taking the
address. The example you give is one of the few cases we _are_
interested in the address, but we can speed up all other accesses to
current by going through the kernel replacing current with __current
in appropriate places.
The above should already speed up the kernel _if_ the mapping scheme
doesn't have weird cache effects etc. (don't know how efficient MIPS
weirdo chips are at this stuff).
Now for the "optional" part :-)
_If_ from going through the kernel it is obvious that __current
will be much more used than current, we no longer have to optimize
addess to current any more than we optimize access to say
__current->mm. Then it would be ok if current required an indirection
to access. So we create a field in task_struct called "this" and
#define current (((struct *task_struct)__current_virt_addr)->this)
Now, the stack and the task_struct are independent (as in 2.0) so we
might not need to allocate 8k block on fork, and the performance
impact of this is very low.
astor
-- Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway http://www.guardian.no/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html