WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] [PATCH] Use saner dom0 memory and vcpu defaults, d

To: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [PATCH] Use saner dom0 memory and vcpu defaults, don't panic on over-allocation
From: Jarod Wilson <jwilson@xxxxxxxxxx>
Date: Wed, 01 Aug 2007 13:25:48 -0400
Cc: Alex Williamson <alex.williamson@xxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 01 Aug 2007 10:23:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <46B0ACEB.3080200@xxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Red Hat, Inc.
References: <46AFF7F6.5090105@xxxxxxxxxx> <1185943424.6802.98.camel@bling> <20070801052434.GC14448%yamahata@xxxxxxxxxxxxx> <46B08EE2.5020106@xxxxxxxxxx> <46B0ACEB.3080200@xxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.5 (X11/20070719)
Jarod Wilson wrote:
> Jarod Wilson wrote:
>> Isaku Yamahata wrote:
>>> On Tue, Jul 31, 2007 at 10:43:44PM -0600, Alex Williamson wrote:
>>>>> +       /* maximum available memory for dom0 */
>>>>> +       max_dom0_pages = avail_domheap_pages() -
>>>>> +                        min(avail_domheap_pages() /
>>>>> +                        16UL, 512UL << (20 - PAGE_SHIFT)) ;
>>>>    I assume this heuristic came from Akio's patch in the thread you
>>>> referenced; can anyone explain how this was derived and why it's
>>>> necessary?  It looks like a fairly random fudge factor.  Thanks,
>>> I guess it comes from compute_dom0_nr_pages() under arch/x86.
>>> However I don't know why compute_dom0_nr_pages() is so.
>>> Anyway It should be different for ia64. While I'm guessing the most
>>> dominant factor is the p2m table, domain0 building process should
>>> be revised for the correct estimation.
>> The version above does seem to work well for me on all the boxes I've
>> tested it on, but I'm definitely all ears for how exactly to obtain a
>> better calculation. I'm not familiar enough with the memory layout to
>> easily come up with it myself, so anyone else has a suggestion there,
>> please do speak up.
> 
> Still reading over code, but throwing this idea out there... Would it
> make sense to use efi_memmap_walk() to determine max_dom0_size? And if
> so, should the size of the xenheap be subtracted from that?

Rather than that approach, a simple 'max_dom0_pages =
avail_domheap_pages()' is working just fine on both my 4G and 16G boxes,
with the 4G box now getting ~260MB more memory for dom0 and the 16G box
getting ~512MB more. Are there potential pitfalls here? I had a brief
explanation for why the fudge factor on x86 was needed that now escapes
me, but I think ia64 may be good to go without it...

--
(XEN) System RAM: 4069MB (4166832kB)
(XEN) size of virtual frame_table: 10256kB
(XEN) virtual machine to physical table: f3fffffff7e00070 size: 2096kB
(XEN) max_page: 0x103fff2
(XEN) allocating frame table/mpt table at mfn 0.
(XEN) Xen heap: 60MB (61664kB)
(XEN) Domain heap initialised: DMA width 32 bits
(XEN) avail:0x1180c60000000000,
status:0x60000000000,control:0x1180c00000000000, vm?0x0
(XEN) No VT feature supported.
(XEN) cpu_init: current=f000000004118000
(XEN) vhpt_init: vhpt paddr=0x40febc0000, end=0x40febcffff
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Time init:
(XEN) .... System Time: 1503261ns
(XEN) .... scale:              11C71C71C
(XEN) num_online_cpus=1, max_cpus=64
(XEN) Brought up 1 CPUs
(XEN) xenoprof: using perfmon.
(XEN) perfmon: version 2.0 IRQ 238
(XEN) perfmon: Itanium 2 PMU detected, 16 PMCs, 18 PMDs, 4 counters (47
bits)
(XEN) Maximum number of domains: 63; 18 RID bits per domain
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Max dom0 size: 3978MB
(XEN) Reducing dom0 memory allocation from 4294967296 to 4172185600 to
fit available memory
--

Note that we've got a reported total of 4069MB up there, and a max dom0
size of 3978MB, so perhaps there's some further tweaking that could be
done, but I think this looks quite reasonable.

-- 
Jarod Wilson
jwilson@xxxxxxxxxx


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
<Prev in Thread] Current Thread [Next in Thread>