* Re: [PATCH 1/1] Page Table cleanup patch [not found] <20070124023828.11302.51100.sendpatchset@weill.orchestra.cse.unsw.EDU.AU> @ 2007-01-24 3:12 ` Nick Piggin 2007-01-25 0:17 ` Paul Cameron Davies 0 siblings, 1 reply; 2+ messages in thread From: Nick Piggin @ 2007-01-24 3:12 UTC (permalink / raw) To: Paul Davies; +Cc: linux-mm, linux-kernel Paul Davies wrote: > This patch is a proposed cleanup of the current page table organisation. > Such a cleanup would be a logical first step towards introducing at least > a partial clean page table interface, geared towards providing enhanced > virtualization oportunities for x86. It is also a common sense cleanup > in its own right. > > * Creates mlpt.c to hold the page table implementation currently held > in memory.c. > * Adjust Makefile > * Move implementation dependent page table code out of > include/linux/mm.h into include/linux/mlpt-mm.h > * Move implementation dependent page table code out of > include/asm-generic/pgtable.h to include/asm-generic/pgtable-mlpt.h > > mlpt stands from multi level page table. Hi Paul, I'm not sure that I see the point of this patch alone, as there is still all the mlpt implementation details in all the page table walkers. Or did you have a scheme to change implementations somehow just using the p*d_addr_next? > -#ifndef __PAGETABLE_PUD_FOLDED > -/* > - * Allocate page upper directory. > - * We've already handled the fast-path in-line. > - */ > -int __pud_alloc(struct mm_struct *mm, pgd_t *pgd, unsigned long address) > -{ > - pud_t *new = pud_alloc_one(mm, address); > - if (!new) > - return -ENOMEM; > - > - spin_lock(&mm->page_table_lock); > - if (pgd_present(*pgd)) /* Another has populated it */ > - pud_free(new); > - else > - pgd_populate(mm, pgd, new); > - spin_unlock(&mm->page_table_lock); > - return 0; > -} > -#else > -/* Workaround for gcc 2.96 */ > -int __pud_alloc(struct mm_struct *mm, pgd_t *pgd, unsigned long address) > -{ > - return 0; > -} > -#endif /* __PAGETABLE_PUD_FOLDED */ ... > -/* Workaround for gcc 2.96 */ > -int __pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address) > -{ > - return 0; > -} > -#endif /* __PAGETABLE_PMD_FOLDED */ Hmm, we're gcc-3.2 minimum now -- let's get rid of that crud? -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH 1/1] Page Table cleanup patch 2007-01-24 3:12 ` [PATCH 1/1] Page Table cleanup patch Nick Piggin @ 2007-01-25 0:17 ` Paul Cameron Davies 0 siblings, 0 replies; 2+ messages in thread From: Paul Cameron Davies @ 2007-01-25 0:17 UTC (permalink / raw) To: Nick Piggin; +Cc: linux-mm, linux-kernel Hi Nick On Wed, 24 Jan 2007, Nick Piggin wrote: > Paul Davies wrote: >> This patch is a proposed cleanup of the current page table organisation. >> Such a cleanup would be a logical first step towards introducing at least >> a partial clean page table interface, geared towards providing enhanced >> virtualization oportunities for x86. It is also a common sense cleanup in >> its own right. >> >> * Creates mlpt.c to hold the page table implementation currently held >> in memory.c. >> * Adjust Makefile * Move implementation dependent page table code out of >> include/linux/mm.h into include/linux/mlpt-mm.h >> * Move implementation dependent page table code out of >> include/asm-generic/pgtable.h to include/asm-generic/pgtable-mlpt.h >> >> mlpt stands from multi level page table. > > Hi Paul, > > I'm not sure that I see the point of this patch alone, as there is still > all the mlpt implementation details in all the page table walkers. Or > did you have a scheme to change implementations somehow just using the > p*d_addr_next? This patch alone doesn't acheive nearly enough. Separating out as much implementation (without tackling the walkers) would be a start though. The MLPT appears to be intrinsic to the kernel owing to its open coding, and starting to isolate its implementation (even partially) is an important step towards destroying this misconception. I strongly prefer not to go down the path of using a scheme to change implementations with p*d_addr_next. I tried this kind of thing early on and it was horribly ugly. There are far cleaner ways to do it. Cheers Paul Davies ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2007-01-25 0:23 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20070124023828.11302.51100.sendpatchset@weill.orchestra.cse.unsw.EDU.AU>
2007-01-24 3:12 ` [PATCH 1/1] Page Table cleanup patch Nick Piggin
2007-01-25 0:17 ` Paul Cameron Davies
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox