LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Zachary Amsden <zach@vmware.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Glauber de Oliveira Costa <gcosta@redhat.com>,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	glommer@gmail.com, tglx@linutronix.de, ehabkost@redhat.com,
	avi@qumranet.com, anthony@codemonkey.ws,
	virtualization@lists.linux-foundation.org, rusty@rustcorp.com.au,
	ak@suse.de, chrisw@sous-sol.org, rostedt@goodmis.org,
	hpa@zytor.com, roland@redhat.com, mtosatti@redhat.com
Subject: Re: [PATCH 0/10] Tree fixes for PARAVIRT
Date: Fri, 18 Jan 2008 14:31:00 -0800	[thread overview]
Message-ID: <479128A4.9070509@goop.org> (raw)
In-Reply-To: <1200693248.21817.157.camel@bodhitayantram.eng.vmware.com>

Zachary Amsden wrote:
> Why are we rushing so much to do 64-bit paravirt that we are breaking
> working configurations?  If the developement is going to be this
> chaotic, it should be done and tested out of tree until it can
> stabilize.
>   

x86.git is out of the mainline tree, and it seems to be working fairly 
smoothly.  I've come to appreciate the "lots of small patches with quick 
turnaround" model that Ingo has been pushing.

> I do not like having to continuously retest and review the x86 branch
> because the paravirt-ops are constantly in flux and the 32-bit code
> keeps breaking.
>   

Most of the activity is pure unification, with paravirt being part of 
that.  It doesn't help that it increases the CONFIG_ combinatorial 
explosion, but "make randconfig" shakes things out fairly quickly.

> We won't be doing 64-bit paravirt-ops for exactly this reason - is there
> a serious justification from the performance angle on modern 64-bit
> hardware?  If not, why justify the complexity and hackery to Linux?
>   

A big part of the rationale is to unify 32 and 64 bit, so that paravirt 
isn't a gratuitous difference between the two.  Also, 32 and 64 bit Xen 
have almost identical interface requirements, so the work is making 
64-bit Xen progress (and lguest64, of course).

    J

  parent reply	other threads:[~2008-01-18 22:31 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-18 17:20 [PATCH 0/10] Tree fixes for PARAVIRT Glauber de Oliveira Costa
2008-01-18 17:20 ` [PATCH 1/10] add missing parameter for lookup_address Glauber de Oliveira Costa
2008-01-18 17:20   ` [PATCH 2/10] add stringify header Glauber de Oliveira Costa
2008-01-18 17:20     ` [PATCH 3/10] provide a native_init_IRQ function to x86_64 Glauber de Oliveira Costa
2008-01-18 17:20       ` [PATCH 4/10] put generic mm_hooks include into PARAVIRT Glauber de Oliveira Costa
2008-01-18 17:20         ` [PATCH 5/10] puts read and write cr8 into pv_cpu_ops Glauber de Oliveira Costa
2008-01-18 17:20           ` [PATCH 6/10] provide read and write cr8 paravirt hooks Glauber de Oliveira Costa
2008-01-18 17:20             ` [PATCH 7/10] fill pv_cpu_ops structure with cr8 fields Glauber de Oliveira Costa
2008-01-18 17:20               ` [PATCH 8/10] add asm_offset PARAVIRT constants Glauber de Oliveira Costa
2008-01-18 17:20                 ` [PATCH 9/10] provide __parainstructions section Glauber de Oliveira Costa
2008-01-18 17:20                   ` [PATCH 10/10] change function orders in paravirt.h Glauber de Oliveira Costa
2008-01-18 20:24                     ` Jeremy Fitzhardinge
2008-01-18 20:41                   ` [PATCH 9/10] provide __parainstructions section Sam Ravnborg
2008-01-18 22:47                     ` Jeremy Fitzhardinge
2008-01-18 20:26   ` [PATCH 1/10] add missing parameter for lookup_address Chris Wright
2008-01-19  1:16     ` Andi Kleen
2008-01-18 20:32 ` [PATCH 0/10] Tree fixes for PARAVIRT Ingo Molnar
2008-01-18 21:37   ` Ingo Molnar
2008-01-18 21:54     ` Zachary Amsden
2008-01-18 22:02       ` Ingo Molnar
2008-01-19  1:24         ` Glauber de Oliveira Costa
2008-01-22 12:20           ` Ingo Molnar
2008-01-18 22:31       ` Jeremy Fitzhardinge [this message]
2008-01-19 18:19 ` [PATCH] fill in missing pv_mmu_ops entries for PAGETABLE_LEVELS >= 3 Marcelo Tosatti
2008-01-20  5:05   ` Jeremy Fitzhardinge
2008-01-21 20:44   ` Eduardo Pereira Habkost
2008-01-21 21:19     ` Jeremy Fitzhardinge
2008-01-22 12:30   ` Ingo Molnar
2008-01-28 22:33     ` Glauber de Oliveira Costa

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=479128A4.9070509@goop.org \
    --to=jeremy@goop.org \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=anthony@codemonkey.ws \
    --cc=avi@qumranet.com \
    --cc=chrisw@sous-sol.org \
    --cc=ehabkost@redhat.com \
    --cc=gcosta@redhat.com \
    --cc=glommer@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mtosatti@redhat.com \
    --cc=roland@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=zach@vmware.com \
    /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).