|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-ia64-devel] [PATCH] Use saner dom0 memory and vcpu defaults, don't panic on over-allocation
Jarod Wilson wrote: > 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. Attached patch is working well for me. It also includes the function name switch from alloc_dom0_size to calc_dom0_size as suggested by Isaku, and an S-O-B. -- Jarod Wilson jwilson@xxxxxxxxxx Some ia64 xen dom0 tweaks:
* Increase default memory allocation from 512M to 4G
* Increase default vcpu allocation from 1 to 4
* If need be, scale down requested memory allocation to fit
available memory, rather than simply panicking
Signed-off-by: Jarod Wilson <jwilson@xxxxxxxxxx>
diff -r 039f2ccb1e38 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.c Tue Jul 31 10:30:40 2007 -0600
+++ b/xen/arch/ia64/xen/domain.c Wed Aug 01 13:44:05 2007 -0400
@@ -52,10 +52,11 @@
#include <asm/perfmon.h>
#include <public/vcpu.h>
-static unsigned long __initdata dom0_size = 512*1024*1024;
+/* dom0_size: default memory allocation for dom0 (~4GB) */
+static unsigned long __initdata dom0_size = 4096UL*1024UL*1024UL;
/* dom0_max_vcpus: maximum number of VCPUs to create for dom0. */
-static unsigned int __initdata dom0_max_vcpus = 1;
+static unsigned int __initdata dom0_max_vcpus = 4;
integer_param("dom0_max_vcpus", dom0_max_vcpus);
extern char dom0_command_line[];
@@ -1195,8 +1196,24 @@ static void __init loaddomainelfimage(st
}
}
-void __init alloc_dom0(void)
-{
+static void __init calc_dom0_size(void)
+{
+ unsigned long max_dom0_pages;
+ unsigned long max_dom0_size;
+
+ /* maximum available memory for dom0 */
+ max_dom0_pages = avail_domheap_pages();
+ max_dom0_size = max_dom0_pages * PAGE_SIZE;
+ printk("Maximum permitted dom0 size: %luMB\n",
+ max_dom0_size / (1024*1024));
+
+ /* validate proposed dom0_size, fix up as needed */
+ if (dom0_size > max_dom0_size) {
+ printk("Reducing dom0 memory allocation from %lu to %lu "
+ "to fit available memory\n", dom0_size, max_dom0_size);
+ dom0_size = max_dom0_size;
+ }
+
/* Check dom0 size. */
if (dom0_size < 4 * 1024 * 1024) {
panic("dom0_mem is too small, boot aborted"
@@ -1261,6 +1278,8 @@ int __init construct_dom0(struct domain
BUG_ON(v->is_initialised);
printk("*** LOADING DOMAIN 0 ***\n");
+
+ calc_dom0_size();
max_pages = dom0_size / PAGE_SIZE;
d->max_pages = max_pages;
diff -r 039f2ccb1e38 xen/arch/ia64/xen/xensetup.c
--- a/xen/arch/ia64/xen/xensetup.c Tue Jul 31 10:30:40 2007 -0600
+++ b/xen/arch/ia64/xen/xensetup.c Wed Aug 01 13:44:31 2007 -0400
@@ -46,7 +46,6 @@ extern void early_setup_arch(char **);
extern void early_setup_arch(char **);
extern void late_setup_arch(char **);
extern void hpsim_serial_init(void);
-extern void alloc_dom0(void);
extern void setup_per_cpu_areas(void);
extern void mem_init(void);
extern void init_IRQ(void);
@@ -469,8 +468,6 @@ void __init start_kernel(void)
trap_init();
- alloc_dom0();
-
init_xenheap_pages(__pa(xen_heap_start), xenheap_phys_end);
printk("Xen heap: %luMB (%lukB)\n",
(xenheap_phys_end-__pa(xen_heap_start)) >> 20,
Attachment:
signature.asc _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ia64-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |