[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
On Fri, Jun 05, 2009 at 11:20:17AM +0100, Ian Campbell wrote: > On Thu, 2009-06-04 at 16:26 -0400, Pasi Kärkkäinen wrote: > > What do you suggest me to try next? > > I'm at a bit of a loss to be honest... > > It's interesting that it's always kswapd0 even in the case with no swap > configured. Were you running with CONFIG_SWAP=n or just with the swap > device turned off? > I just ran "swapoff -a" before testing.. > Judging from the backtrace the sequence of events seems to be roughly: > kswapd<0> runs and calls balance_pgdat which calls shrink_zone who in > turn calls shrink_active_list if inactive_anon_is_low() (so I think we > are dealing with anon pages). shrink_active_list() then iterates over a > list of pages calling page_referenced() on each one. page_referenced() > eventually calls down to page_referenced_one() (presumably via > page_referenced_anon()) and eventually to page_check_address() which > walks the page table and attempts to map the PTE page. This goes via > pte_offset_map() to kmap_atomic_pte() then xen_kmap_atomic_pte(). Here > we check if the page is pinned and then attempt to map it, since we > _think_ the page is not pinned the mapping is writable. However at this > point Xen reports that the page really is pinned (28000001 => Page Type > 1 == L1 PT) and we are trying to make a writable mapping (e0000000 => > Page Type 7 == Writable) which is disallowed. > > Do you know which line of xen_set_pte() the fault is occurring at? I > assume either "ptep->pte_high =" or "ptep->pte_low =". > I haven't looked for that.. I guess I should compile debug=y Xen build again. > So the question is -- how come we have a page which is pinned but this > fact is not recorded in the struct page information? It might be > interesting to know if the corresponding L3 PT is pinned. If the mm is > active then this should always be the case and I _think_ it would be a > bug for the L3 to be pinned but not all the which L1s which it contains. > Can you try this patch which tries to notice this situation and prints > some potentially interesting information, similarly on the fault it > dumps a little more info. Since I can't repro I've only tested that it > doesn't break normal use, I've not actually seen the debug trigger... > OK. I'll try later today.. > > > I'd guess that this would at least work around the issue, I doubt it's a > proper fix and it's going to shaft perf I suspect (not that highpte > won't be doing a pretty good job of that ;-)). > > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c > index fefdeee..4c694e4 100644 > --- a/arch/x86/xen/mmu.c > +++ b/arch/x86/xen/mmu.c > @@ -1521,7 +1521,7 @@ static void *xen_kmap_atomic_pte(struct page *page, > enum km_type type) > { > pgprot_t prot = PAGE_KERNEL; > > - if (PagePinned(page)) > + if (1 || PagePinned(page)) > prot = PAGE_KERNEL_RO; > > if (0 && PageHighMem(page)) > I'll try just the first debug-patch first.. so I won't apply this one yet. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |