Alex:
It becomes much clear now that multiple softsware TLB support is a must in
functionality. For at least following reasons:
1: We should merge VTI and para domain vMMU code together to reduce
future maintaince effort. In this case multiple software TLB support for MMIOs
is a
On Thu, 2006-04-13 at 20:20 +0800, Dong, Eddie wrote:
Anthony's patch is ready to support all of above as a functionality
ready solution, and so far I didn't see anybody against multiple
software TLB support. Can u check in now as a build option? The
performance difference in 1-2 percent
Le Vendredi 07 Avril 2006 21:02, Xu, Anthony a écrit :
Hash vTLB is intended to address SMP scalability for large system.
If I understand correctly, the Hash vTLB patch doesn't handle itc whose ps
rr.ps (there is a panic here).
After a few minutes of thinking, I don't see how this could be
From: Tristan Gingold
Sent: 2006年4月12日 16:38
To: Xu, Anthony; xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-ia64-devel] [PATCH] [Resend]Enable hash vtlb
Le Mercredi 12 Avril 2006 10:01, Xu, Anthony a écrit :
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
Sent: 2006年4月12日 15:53
To: Xu
Le Vendredi 07 Avril 2006 21:02, Xu, Anthony a écrit :
Hash vTLB is intended to address SMP scalability for large system.
I don't really understand this.
From my point of view, your patches add 3 changes:
* VHPT is per VP (and not LP).
* Collision chains
* itc large pages correctly handled.
I
Hi Tristan
Thanks for your comments
From: Tristan Gingold
Sent: 2006年4月10日 19:37
Le Vendredi 07 Avril 2006 21:02, Xu, Anthony a écrit :
Hash vTLB is intended to address SMP scalability for large system.
I don't really understand this.
From my point of view, your patches add 3 changes:
* VHPT
Le Lundi 10 Avril 2006 14:24, Xu, Anthony a écrit :
Hi Tristan
[...]
Because it is per VP VHPT, seems it is easier to support SMP-g.
In my mind, it's more natural to use IPI to emulate ptc.g.
In my experience, this is very slow. I will publish figures later.
I know your method of emulating
Hi Alex,
Below data is got based on changeset 8489.
System:
Tiger 4
4G RAM (2GB available to xen)
Montecito 1.4GHz dual core dual thread.
DomU 512M RAM
bare metal (UP):
Total TimeBuild Time 2 Build Time 1
On Mon, 2006-04-10 at 22:07 +0800, Xu, Anthony wrote:
Hi Alex,
Below data is got based on changeset 8489.
System:
Tiger 4
4G RAM (2GB available to xen)
Montecito 1.4GHz dual core dual thread.
DomU 512M RAM
Adding memory might be interesting. Perhaps there's
On Mon, 2006-04-10 at 23:01 +0800, Xu, Anthony wrote:
If we configure domU with memory 256MB, domU will complain at least 256M
is needed.
Yes there should a best ratio of memory size of domU and size of VHPT.
My tests are:
dom0: boot w/ dom0_mem=768M, kill off all daemons, build
domU: boot
The attachment is the script which I used to get kernel
build performance.
Usage Example,
./make_kernel.sh2/root/linux-2.6.16.tar.bz2
(times of build) (absolute path)
The attachment seems to have been lost to a virus
scanner. My test
was simply:
I wonder if the time command is appropriate for measuring
performance in a domU? Are we sure the real component
is measuring elapsed wall clock time? If not, perhaps
time is not accounting for time spent in the hypervisor
and time spent in dom0 (e.g. backend drivers).
In all my past
-devel@lists.xensource.com
Subject: RE: [Xen-ia64-devel] [PATCH] [Resend]Enable hash vtlb
On Mon, 2006-04-10 at 23:01 +0800, Xu, Anthony wrote:
If we configure domU with memory 256MB, domU will complain at least
256M
is needed.
Yes there should a best ratio of memory size of domU and size of VHPT
On Mon, 2006-04-10 at 16:20 -0700, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
FYI, I did a preliminary test and found that time and
date +%s are yielding essentially the same result for dom0,
even with dom0 also doing Linux builds. So ignore that
question.
Good to know, thanks for
From: Magenheimer, Dan (HP Labs Fort Collins)
Sent: 2006年4月11日 0:21
Even if time checks out OK, I am still astonished if domU
is faster than native and suspect that there is something
wrong with either the measurement or the methodology.
Dan
Just noted a previous similar report from xen-devel
Hi Alex,
I'll kill off all daemons on native and Dom0, and I'll try
to enlarge memory on Dom0 and DomU.
I'll send out the data later.
Thanks,
Anthony
From: Alex Williamson
Sent: 2006?4?10? 23:14
To: Xu, Anthony
Cc: xen-ia64-devel@lists.xensource.com
Subject: RE: [Xen-ia64-devel] [PATCH
Hi Anthony,
There are a few new warnings in the xen build with this patch, but
most importantly, my system fails to boot with this patch applied. I've
attached boot logs both with and without this patch. As you can see
there are a bunch of general exceptions reflected to dom0 as soon as
init
On Mon, 2006-04-10 at 09:09 +0800, Xu, Anthony wrote:
Hi Alex,
Sorry for not clear.
You need to apply three patches I sent before applying this one.
They are,
1. get_pfn_list workaround.
2. warning fix
3. access reflect fix
I attach these three patches.
Hi Anthony,
Thanks, I applied
On Sun, 2006-04-09 at 23:10 -0600, Alex Williamson wrote:
Thanks, I applied all the patches to my test tree and am able to
boot. However, I'm not able to reproduce the performance increase for
domU. I see a performance decrease across the board (including a
significant increase in system
19 matches
Mail list logo
