LKML Archive on
help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <>
To: Andi Kleen <>
Cc: Jeremy Fitzhardinge <>,,
	Andrew Morton <>,
	lkml <>,
	Rusty Russell <>
Subject: Re: [patch 4/6] Convert PDA into the percpu section
Date: Fri, 30 Mar 2007 20:00:41 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.


  parent reply	other threads:[~2007-03-31  3:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-31  2:00 [patch 0/6] i386 gdt and percpu cleanups Jeremy Fitzhardinge
2007-03-31  2:00 ` [patch 1/6] i386: Account for module percpu space separately from kernel percpu Jeremy Fitzhardinge
2007-03-31  2:00 ` [patch 2/6] Allow percpu variables to be page-aligned Jeremy Fitzhardinge
2007-03-31  2:00 ` [patch 3/6] Page-align the GDT Jeremy Fitzhardinge
2007-03-31  2:00 ` [patch 4/6] Convert PDA into the percpu section Jeremy Fitzhardinge
2007-03-31  2:35   ` Andi Kleen
2007-03-31  2:54     ` Rusty Russell
2007-03-31  3:00     ` Jeremy Fitzhardinge [this message]
2007-03-31  2:00 ` [patch 5/6] cleanups to help using per-cpu variables from asm Jeremy Fitzhardinge
2007-03-31  2:00 ` [patch 6/6] Define per_cpu_offset Jeremy Fitzhardinge
2007-03-31  2:56 ` [patch 0/6] i386 gdt and percpu cleanups Rusty Russell
2007-03-31  3:05   ` Jeremy Fitzhardinge
2007-03-31  3:16 ` Jeremy Fitzhardinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [patch 4/6] Convert PDA into the percpu section' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).