Andi Kleen wrote:
> On Saturday 31 March 2007 04:00, Jeremy Fitzhardinge wrote:
>
>> Currently x86 (similar to x84-64) has a special per-cpu structure
>> called "i386_pda" which can be easily and efficiently referenced via
>> the %fs register. An ELF section is more flexible than a structure,
>> allowing any piece of code to use this area. Indeed, such a section
>> already exists: the per-cpu area.
>>
>
> Hmm, I'm a little reluctant. This moves i386 more away from x86-64
> again. If we ever merge them it would mean more work. Do you really need it?
It cleans things up a fair bit:
1. At initialization, it doesn't require %fs to be loaded before
being able to use per-cpu variables, since you can use percpu with
%fs set to a plain 0-based 4G segment; you can defer
initialization until SMP bringup (which is never on a UP kernel).
PDA requires %fs to be specially set up to point to an initial
PDA, which includes setting up a gdt entry, generally before C
code is run. For paravirtualized boot, this setup needs to be
replicated by each hypervisor startup sequence; without the PDA,
it becomes a non-issue (especially since hypervisors typically
start up with %fs as a flat segment anyway). Overall, both UP and
SMP boot is simpler and less fragile.
2. Adding things to the pda requires changing <asm/pda.h>, which
often means including extra headers to allow added definitions.
Since pda.h is used to implement things like "current" and
"smp_processor_id", it gets included everywhere. Any header
included in <asm/pda.h> effectively gets included everywhere in
the kernel. Also, it turns pda.h into a concentrated nest of
patch conflicts. percpu requires no central modifications to add
a new percpu variable.
3. There's no disadvantage to using a percpu at all, especially if
you can use the x86_*_percpu functions which allow direct access
to the variable via %fs. If one construct will do, why have two?
Removing the pda removes quite a bit of unnecessary code.
4. I think, ultimately, it would be better to migrate x86_64 away
from using the pda to all percpu too, though this has some tricky
bits for now.
Certainly, not having this patch at this stage will require me to rework
quite a few of the later patches. I was going to put off sending out
this patch until later, but reworking everything to work both with pda
and percpu was so fragile and tricky-bug-prone that I decided to push it
early and save myself a lot of work.
J
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
