lkml.org 
[lkml]   [2002]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: thread_info implementation
Hi,

On Mon, 11 Feb 2002, David S. Miller wrote:

> It keeps your platform the same, and it does help other platforms.
> It is the nature of any abstraction change we make in the kernel
> that platforms have to deal with.

Of what "abstraction change" are you talking about?
Any change should usually help most architectures and so far the
thread_info change has only be done a few.

> 2) pointer dereference causes performance problems
>
> ummm no, not really, go test it for yourself if you don't
> believe me
>
> This only leaves "I don't want to do the conversion because it has
> no benefit to ia64." Well, it doesn't hurt your platform either,
> so just cope :-)

That's simply not true. An extra load might be cheap, maybe on sparc it's
even free, but on most architectures it has a cost. Additionally every
access to current requires an extra load, so every function which uses
current will be larger, all embedded targets will thank you for that.
Where is the problem to allow these two implementations:
1.
#define current_thread_info() asm(...)
#define current current_thread_info()->task
2.
#define current asm(...)
#define current_thread_info() &current->thread_info

If you're unable to properly compute your structure offsets, you're free
to use the first version, I prefer the second.

bye, Roman


-
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/

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