* William Lee Irwin III ([EMAIL PROTECTED]) wrote: > * Christoph Lameter ([EMAIL PROTECTED]) wrote: > >> +#ifdef CONFIG_HIGHMEM64G > >> +#define __pgd_alloc() kmem_cache_alloc(pgd_cache, > >> GFP_KERNEL|__GFP_REPEAT) > >> +#define __pgd_free(pgd) kmem_cache_free(pgd_cache, pgd) > > On Wed, Mar 28, 2007 at 03:26:56PM -0700, Chris Wright wrote: > > I must've glazed over something, I thought this was removal of slabs? > > The pgd slab is not fully removable in the PAE case because a dedicated > slab is the only way to enforce alignment for allocations as small as > PAE PGD's.
Heh, yeah "page sized" is the part i glazed over, my fault. > On Wed, Mar 28, 2007 at 03:26:56PM -0700, Chris Wright wrote: > > BTW, this will interact shared_kernel_pmd patch that Jeremy's posted a > > few times (I know at least wli has looked over that one). We need to > > make sure that PAE under at least Xen hypervisor has a page-sized pgd, > > although the mmlist chaining looks nice to me. > > That, not to mention the total lack of verification of the pageattr.c > code, are among the reasons I didn't want it posted. > > > * Christoph Lameter ([EMAIL PROTECTED]) wrote: > >> + memcpy(&pgd[USER_PTRS_PER_PGD], &swapper_pg_dir[USER_PTRS_PER_PGD], > >> + KERNEL_PGD_PTRS*sizeof(pgd_t)); > > On Wed, Mar 28, 2007 at 03:26:56PM -0700, Chris Wright wrote: > > clone_pgd_range() for consistency? and it seems we lost a > > paravirt_alloc_pd_clone() in there somewhere. > > Yes, another reason why it shouldn't have been posted as-is. It was not > intended to for anything more than comparative benchmarking on systems > without graphics running on the bare metal as opposed to Xen/etc. guests. OK, all good here. Just wanted to make sure things didn't collide too badly. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
