Re: [RFC 00/15] x86_64: Optimize percpu accesses

[Jeremy Fitzhardinge]

Mike Travis wrote:
> I did compartmentalize the changes so they were in separate patches,
> and in particular, by separating the changes to the include files, I
> was able to zero in on some problems much easier.
>
> But I have no objections to leaving the cpu_pda ops in place and then,
> as you're suggesting, extract and modify the fields as appropriate.
>
> Another approach would be to leave the changes from XXX_pda() to
> x86_percpu_XXX in place, and do the patches with simply changing
> pda.VAR to VAR .)
>   

Yes, but that's still two patches where one would do.  If I'm going to 
go through the effort of reconciling your percpu patches with my code, 
I'd like to be able to remove some #ifdef CONFIG_X86_64s in the process.

> In any case I would like to get this version working first, before
> attempting that rewrite, as that won't change the generated code.
>   

Well, as far as I can tell the real meat of the series is in 1-3 and the 
rest is fluff.  If just applying 1-3 works, then everything else should too.

> Btw, while I've got your attention... ;-), there's some code in
> arch/x86/xen/smp.c:xen_smp_prepare_boot_cpu() that should be looked
> at closer for zero-based per_cpu__gdt_page:
>
> 	make_lowmem_page_readwrite(&per_cpu__gdt_page);
>
> (I wasn't sure how to deal with this but I suspect the __percpu_offset[]
> or __per_cpu_load should be added to it.)

Already fixed in the mass of patches I posted yesterday.  I turned it 
into &per_cpu_var(gdt_page)).

   J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/