Re: Using %cr2 to reference "current"

[Michael Barabanov <baraban@fsmlabs.com>]

Here's my version of hard cpu id (RTLinux version):

extern inline int rtl_getcpuid(void)
{
        unsigned cpu;
        __asm__ (
                        "str %%ax\n\t"
                        "shr $5, %%eax\n\t"
                        "sub $3, %%eax\n\t"
                        : "=a"(cpu));
        return cpu;
}

No cr2 involved; extremely fast. This takes advantage of the fact that
TSS-CPU mapping is 1-1 in 2.4.

Michael.

Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> > I too am confused.  More so, the difference between hard_get_current and
> > get_current is confusing.  I further question things because I suspect
> 
> hard_get_current always works
> get_current assumes %cr2 is loaded correctly
> 
> > do_page_fault, cpu_init" but all these functions call other functions
> > that may very well use get_current.  How is this going to work?
> 
> do_page_fault and cpu_init load %cr2
> 
> > Further, the preemptible kernel patch oopses with this patch (IOW, don't
> > use 2.4.13-ac8 + preempt-kernel, unless you remove all these bits like I
> > did :>).  I think it may be because of:
> 
> You must ensure that you don't pre-empt until %cr2 is loaded. Obviously this
> isnt a problem with the traditional low latency patch but if you pre-empty
> very early in page fault handling then I suspect you might get the odd
> suprise.
> 
> The reasoning behind all this is to fix the cache pessimal nature of the x86
> stack layout - we had all task structs on the same cache colour and all 
> stacks aligned within pages (so every apache thread waiting at the same
> point is on the same colour too and each wait queue entry on their stacks
> is linked to entries all the same colour)
> 
> Alan