RE: [Xen-ia64-devel] CONFIG_DOMAIN0_CONTIGUOUS in domain.c - Magenheimer, Dan (HP Labs Fort Collins) - com.xensource.lists.xen-ia64-devel

10 messages in com.xensource.lists.xen-ia64-develRE: [Xen-ia64-devel] CONFIG_DOMAIN0_C...

From	Sent On	Attachments
Dong, Eddie	26 Feb 2006 23:53
Zhang, Xiantao	27 Feb 2006 20:31
Isaku Yamahata	27 Feb 2006 21:46
Dong, Eddie	27 Feb 2006 22:04
Tian, Kevin	27 Feb 2006 22:14
Magenheimer, Dan (HP Labs Fort Collins)	28 Feb 2006 08:52
Dong, Eddie	28 Feb 2006 15:18
Magenheimer, Dan (HP Labs Fort Collins)	28 Feb 2006 15:35
Yang, Fred	28 Feb 2006 16:51
Dong, Eddie	28 Feb 2006 16:56

Subject:	RE: [Xen-ia64-devel] CONFIG_DOMAIN0_CONTIGUOUS in domain.c
From:	Magenheimer, Dan (HP Labs Fort Collins) (dan....@hp.com)
Date:	02/28/2006 03:35:55 PM
List:	com.xensource.lists.xen-ia64-devel

This isn't a performance issue. I don't think domain0/U will function correctly with CONFIG_...CONTIGUOUS undef'd until all of Isaku's necessary VP+DMA changes (in Xen, Xenlinux, Xen drivers, and possibly tools) are complete.

-----Original Message----- From: Dong, Eddie [mailto:eddi...@intel.com] Sent: Tuesday, February 28, 2006 4:19 PM To: Magenheimer, Dan (HP Labs Fort Collins); Tian, Kevin; Isaku Yamahata Cc: xen-...@lists.xensource.com Subject: RE: [Xen-ia64-devel] CONFIG_DOMAIN0_CONTIGUOUS in domain.c

Magenheimer, Dan (HP Labs Fort Collins) wrote:

to VP. HOWEVER... it may be possible and desirable for much of Isaku's work to support both VP and P==M. For non-I/O code, CONFIG_DOMAIN0_CONTIGUOUS could be used (or possibly renamed) to select VP or P==M at compile-time, at least until the conversion to VP+DMA is complete. This would allow at least some of Isaku's

As if eventually we will remove this code, putting an compile option now is OK IMO. But I think the default one should be #undefed by some pre-cleanip patch now so that people can find issues earlier if there have. #undef this one can support no matter p==m or p!=m, while #define this can only support p==m. Yes maybe we will see 0.5% performance degradation with #undef, but this is a functionality must as we all go toward p!=m :-( After the whole p2m/VP patch comes out, we can then do more performance tuning :-) Eddie