[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] RE: [Question] Why code differs in construct_dom0?
I do not know why kernel does this. But I do know that GART table in Intel platform supports 64bit addresses. So in theory, allocating memory above 4G should be OK. Large memory requirement should be the result of architecture of onboard graphic card. It has no own memory on card. Memory requirements must be fulfilled by allocating from system memories. Seems there is no good solution. Like what you said, a message asking for setting dom0_mem may be better. Shan Haitao -----Original Message----- From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx] Sent: 2008年11月20日 21:13 To: 'Keir Fraser'; Shan, Haitao Cc: 'xen-devel@xxxxxxxxxxxxxxxxxxx' Subject: [Xen-devel] RE: [Question] Why code differs in construct_dom0? >>> "Shan, Haitao" <haitao.shan@xxxxxxxxx> 20.11.08 13:52 >>> >I think I may not have described the problem clearly. The system has 4G >memory. From E820 table, there was near 3.5G usable ram below 4G >and about 0.5G above 4G. Of all the ram, most of the memory was >allocated to dom0, leaving only those for xen >itself such as xenheap >and xen's reservations. >We were using an onboard graphic card. When starting X, agpgart allocated memory from kernel, then asked xen to exchange these >pages to contiguous pages below 4G. Each time agpgart module did >this job, some pages in kernel (which are actually >above 4G in >physical memory) were replaced with contiguous pages below 4G. >These kind of demands were rather high, about 256M in our platform. >Finally, xen's reservation (128M) was not enough to fulfill this >requirement. >Why was the reservation exhausted? Because kernel kept asking for >memory below 4G but only returning to xen memory above 4G. Then >why is agpgart's allocation always in effect from above 4G? According >to the code I pasted in my first mail, when pfn in >dom0 was small in >number, mfn was large. The smaller the pfn was, the larger the >corresponding mfn was. Apggart allocated memory with GFP_DMA32 >set, so the pfns allocated was likely to be small. Then the mfns were >likely to be actually quite large (above 4G). > >Either increasing the reservation (like 384M) or changing the initial p2m >mapping in dom0 can solve the problem, and our tests verified this >judgment. We do not know which solution is better. That's why we are >seeking your kindly help. I am not sure if I have explained clearly >enough so far. So any questions on the problem itself, Keir? Neither of the suggested solutions seems correct to me - both would only defer the point where the problem occurs. The question really is why agpgart needs so much memory below 4G. And if that really isn't a bug somewhere else, then requiring a sufficiently large negative value to be passed with dom0_mem= would seem to be the only option on this system (but not as a global default). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |