Messages in this thread | | | Date | Sat, 7 Dec 2002 00:57:07 +0100 | From | Andrea Arcangeli <> | Subject | Re: Maybe a VM bug in 2.4.18-18 from RH 8.0? |
| |
On Fri, Dec 06, 2002 at 03:45:24PM -0800, William Lee Irwin III wrote: > On Sat, Dec 07, 2002 at 12:32:43AM +0100, Andrea Arcangeli wrote: > > but note that even with rmap you don't know the pmd that points to the > > pte that you want to relocate and for the anon pages you miss > > information about mm and virtual address where those pages are > > allocated, so basically rmap is useless for doing it, you need to do the > > pagetable walking ala swap_out, in turn it's not easier at all in 2.5 > > than it could been in 2.4 (but of course this is a 2.5 thing only, I > > just want to say that if it's not difficult in 2.5 it wasn't difficult > > in 2.4 either). > > Actually, we do. From include/asm-generic/rmap.h: > > static inline void pgtable_add_rmap(struct page * page, struct mm_struct * mm, unsigned long address) > { > #ifdef BROKEN_PPC_PTE_ALLOC_ONE > /* OK, so PPC calls pte_alloc() before mem_map[] is setup ... ;( */ > extern int mem_init_done; > > if (!mem_init_done) > return; > #endif > page->mapping = (void *)mm; > page->index = address & ~((PTRS_PER_PTE * PAGE_SIZE) - 1); > inc_page_state(nr_page_table_pages); > } > > So pagetable pages are tagged with the right information, and in > principle could even be tagged here with the pmd in page->private.
sorry I didn't noticed the overlap of page->mapping to store the mm. But yes, I should have realized that you had do because otherwise you wouldn't know how to flush the tlb ;) so without the mm and address rmap would be useless. So via the address and mapping you can walk the pagetables and reach it with lower complexity than w/o rmap. Still doing the pagetable walk wouldn't be an huge increase in complexity but it would increase the "computational" complexity of the algorithm.
> These fields are actually required for use by try_to_unmap_one(), > and something similar could be done for a try_to_move_one(). This > information remains intact with shared pagetables, and is generalized > so that the PTE page is tagged with a list of mm's (the mm_chain), > and in that case no unique pmd could be directly stored in the page, > but it could just as easily be derived from the mm's in the mm_chain. > > But there's no denying it would involve a substantial amount of work. > > > Bill
Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |