LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* 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;
as well as URLs for NNTP newsgroup(s).