Re: [uClinux-dev] Kernel 2.6 size increase - get_current()?

David McCullough
2003-07-24T04:53:38Z

Jivin Bernardo Innocenti lays it down ...
> On Thursday 24 July 2003 00:37, Alan Cox wrote:
>
> > On Mer, 2003-07-23 at 23:35, Bernardo Innocenti wrote:
> > > It's a sequence of 6 instructions, 18 bytes long, clobbering 4 registers.
> > > The compiler cannot see around it.
> > > This takes 18*11 = 198 bytes just for invoking the 'current'
> > > macro so many times.
> >
> > Unless you support SMP I'm not sure I understand why m68k nommu changed
> > from using a global for current_task ?
>
> The people who might know best are Greg and David from SnapGear.
> I'm appending them to the Cc list.
>
> But I noticed that most archs in 2.6 do like this. Is it some kind
> of flock-effect? Things get changed in i386 and all other archs
> just follow... :-)

It's a little this way for sure.

Back when I first did the 2.4 uClinux port, the m68k MMU code was
dedicating a register (a2) for current. I thought that was a bad idea
given how often you run out of registers on the 68k, and made it a
global. Because it was still effectively a pointer, the code size
change was not a factor. I just didn't want to give up a register.
So that is the 2.4 history and it has served us well so far ;-)

On the 2.5/2.6 front, I think the change comes from the 8K (2 page) task
structure and everyone just masking the kernel stack pointer to get the
task pointer. Gerg would know for sure, he did the 2.5 work in this area.
We should be easily able to switch back to the current_task pointer with a
few small mods to entry.S.

A general comment on the use of inline throughout the kernel. Although
they may show gains on x86 platforms, they often perform worse on
embedded processors with limited cache, as well as adding size. I
can't see any way of coding around this though. As long as x86 is
driving influence, other platforms will jut have to deal with it as
best they can.

Cheers,
Davidm

--
David McCullough, davidm@snapgear.com Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org