Re: [Xen-ia64-devel] [PATCH] [RFC] paravirt_alt

[Alex Williamson <alex.williamson@xxxxxx>]

On Tue, 2007-07-17 at 11:41 +0900, Isaku Yamahata wrote: 
> On Sun, Jul 15, 2007 at 10:27:19PM -0600, Alex Williamson wrote:
> 
> > Is there a file missing in the patch?
> 
> Sorry. I accidently dropped the part of the patch.
> I attached the newly updated one and the diff from the prefious one.
> 
> 
> Supplemental note;
> CONFIG_PARAVIRT_ENTRY is for generalization.
> so performance optimized configuration is as follows.
> CONFIG_PARAVIRT_ALT=y
> CONFIG_PARAVIRT_NOP_B_PATCH=y
> CONFIG_PARAVIRT_ENTRY=n

Hi Isaku,

   This is a very interesting patch, and quite well done.  Nice work.
If I understand correctly, the performance benefit of ENTRY=n is that
br.cond.sptk.many is overwritten with a nop, so we fall through to the
xen code without the branch penalty that the generic paravirt_entry code
causes, correct?  For a xenlinux kernel running on bare metal, it seems
there's no performance difference between ENTRY=y/n.  I assume ENTRY=y
would be necessary to support a non-Xen PV technology, correct?

  I haven't found a significant performance difference with the patch,
but the potential certainly seems to exist for it.  My tests may not be
producing enough memory pressure to really see an improvement from
removing the running_on_xen memory reference.

   Would the long term plan for the paravirt_*.c files (excluding
paravirt_xen.c) be to move to arch/ia64/kernel, or maybe
arch/ia64/kernel/paravirt?  For now the xen directory may be an
appropriate place since there isn't another caller.

   One minor typo I found; in the definition of inst_b1, s/bypte/btype/.
Thanks,

        Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel