linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Linus Torvalds <torvalds@osdl.org>,
	Jeffrey Sheldon <jeffshel@vmware.com>,
	Ole Agesen <agesen@vmware.com>, Shai Fultheim <shai@scalex86.org>,
	Andrew Morton <akpm@odsl.org>, Jack Lo <jlo@vmware.com>,
	Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Virtualization Mailing List <virtualization@lists.osdl.org>,
	Chris Wright <chrisw@osdl.org>, Martin Bligh <mbligh@mbligh.org>,
	Pratap Subrahmanyam <pratap@vmware.com>,
	Christopher Li <chrisl@vmware.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Zwane Mwaikambo <zwane@arm.linux.org.uk>, Andi Kleen <ak@muc.de>,
	Zachary Amsden <zach@vmware.com>
Subject: [PATCH 0/3] GDT virtualization performance
Date: Thu, 22 Sep 2005 00:35:29 -0700	[thread overview]
Message-ID: <200509220735.j8M7ZT6b000921@zach-dev.vmware.com> (raw)

Three patches to clean up GDT access in Linux to make it friendly to
virtualization environments.  The basic problem is that the GDT must
be write protected, which causes spurious overhead when the GDT lies
on the same page as other data.  This problem exists both for VMware
and Xen; Xen actually requires page isolation, so we have implemented
the most general and compatible solution.

Patch 1 deprecates a broken GDT reference;
Patch 2 adds a per-cpu GDT accessor;
Patch 3 moves the GDT out of the per-cpu area and makes it page
 padded and page aligned.

The GDTs for secondary processors are allocated dynamically to avoid
bloating kernel static data with GDTs for not-present processors.

This could be adapted to drop and reallocate GDTs for CPU hotplug
if desired, although the space savings (1 page) are dubious, so
I have not implemented that at this time.

Testing: 4 way SMP boot-halts, kernel compiles, stress.

Zachary Amsden <zach@vmware.com>

                 reply	other threads:[~2005-09-22  7:37 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=200509220735.j8M7ZT6b000921@zach-dev.vmware.com \
    --to=zach@vmware.com \
    --cc=agesen@vmware.com \
    --cc=ak@muc.de \
    --cc=akpm@odsl.org \
    --cc=chrisl@vmware.com \
    --cc=chrisw@osdl.org \
    --cc=hpa@zytor.com \
    --cc=jeffshel@vmware.com \
    --cc=jlo@vmware.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@mbligh.org \
    --cc=mingo@elte.hu \
    --cc=pratap@vmware.com \
    --cc=shai@scalex86.org \
    --cc=torvalds@osdl.org \
    --cc=virtualization@lists.osdl.org \
    --cc=zwane@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).