Re: thread_info implementation

[Jeff Garzik <jgarzik@mandrakesoft.com>]

Roman Zippel wrote:
> 
> 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

...or number 3, do a conversion to 2.5.4 thread_info then embed the task
structure inside struct thread_info, like what was just done with VFS
inodes.  (embedding the general struct in the arch-specific struct would
make sense to me, whereas I can definitely see how embedding the
arch-specific struct in the general struct would be annoying)

	Jeff



-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com