Re: 2.4.23aa2 (bugfixes and important VM improvements for the highend)

[Dave Hansen]

On Fri, 2004-02-27 at 23:05, Andrea Arcangeli wrote:
> > I'm not sure it's that straightforward really - doing the non-pgd aligned
> > split is messy. 2.5 might actually be much cleaner than 3.5 though, as we
> > never updated the mappings of the PMD that's shared between user and kernel.
> > Hmmm ... that's quite tempting.
> 
> I read the 3.5:0.5 PAE sometime last year and it was pretty
> strightforward too, the only single reason I didn't merge it is that
> it had the problem that it changed common code that every archs depends
> on, so it broke all other archs, but it's not really a matter of
> difficult code, as worse it just needs a few liner change in every arch
> to make them compile again. So I'm quite optimistic 2.5:1.5 will be
> doable with a reasonably clean patch and with ~zero performance downside
> compared to 3:1 and 2:2.

The only performance problem with using PMDs which are shared between
kernel and user PTE pages is that you have a potential to be required to
instantiate the kernel portion of the shared PMD each time you need a
new set of page tables.  A slab for these partial PMDs is quite helpful
in this case.  

The real logistical problem with partial PMDs is just making sure that
all of the 0 ... PTRS_PER_PMD loops are correct.  The last few times
I've implemented it, I just made PTRS_PER_PMD take a PGD index, and made
sure to start all of the loops from things like pmd_index(PAGE_OFFSET)
instead of 0.  

Here are a couple of patches that allowed partial user/kernel PMDs. 
These conflicted with 4:4 and got dropped somewhere along the way, but
the generic approaches worked.  I believe they at least compiled on all
of the arches, too.  

ftp://ftp.kernel.org/pub/linux/kernel/people/mbligh/patches/2.5.68/2.5.68-mjb1/540-separate_pmd
ftp://ftp.kernel.org/pub/linux/kernel/people/mbligh/patches/2.5.68/2.5.68-mjb1/650-banana_split

-- dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/