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
next prev 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: linkBe 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).