Re: 2.5.73-mm2

From: William Lee Irwin III (wli@holomorphy.com)
Date: Sat Jun 28 2003 - 15:49:38 EST


On Sat, Jun 28, 2003 at 08:54:36AM -0700, William Lee Irwin III wrote:
>> +config HIGHPMD
>> + bool "Allocate 2nd-level pagetables from highmem"
>> + depends on HIGHMEM64G
>> + help
>> + The VM uses one pmd entry for each pagetable page of physical
>> + memory allocated. For systems with extreme amounts of highmem,
>> + this cannot be tolerated. Setting this option will put
>> + userspace 2nd-level pagetables in highmem.

On Sat, Jun 28, 2003 at 05:08:37PM +0100, Christoph Hellwig wrote:
> Does this make sense for !HIGHPTE? In fact does it make sense to
> carry along HIGHPTE as an option still? ..

It's both possible and functional, if that's the question. I basically
decided I'd enforce the minimum policy, though it is possible to
entangle the two. I'll make it depends on HIGHMEM64G && HIGHPTE for now.

On Sat, Jun 28, 2003 at 08:54:36AM -0700, William Lee Irwin III wrote:
>> +#ifndef CONFIG_HIGHPMD /* Oh boy. Error reporting is going to blow major goats. */

On Sat, Jun 28, 2003 at 05:08:37PM +0100, Christoph Hellwig wrote:
> Any chance you can rearragne the code to avoid the ifndef in favour
> of an ifdef?

Okay.

On Sat, Jun 28, 2003 at 08:54:36AM -0700, William Lee Irwin III wrote:
>> set_pte(dst_pte, entry);
>> + pmd_unmap(dst_pte);
>> + pmd_unmap_nested(src_pte);

On Sat, Jun 28, 2003 at 08:54:36AM -0700, William Lee Irwin III wrote:
> <Lots more pmd_unmap* calls snipped>
> Looks like you changed some API so that pmds are now returned mapped?
> It might make sense to change their names into foo_map then so the
> breakage is at the API level if someone misses updates for the changes.

It's entirely analogous to pte_offset_map()/pte_alloc_map(). I stubbed
out the things for all architectures already, so it should only be a
question of additional functionality for 32-bit architectures
supporting PAE-like mechanisms. It looks like some mips64, m68k, and
other bits fell out of my tree. They're restored in the real content of
this followup with matching definition counts for all arches.

On Sat, Jun 28, 2003 at 05:08:37PM +0100, Christoph Hellwig wrote:
>> +#ifdef CONFIG_HIGHPMD
>> +#define GFP_PMD (__GFP_REPEAT|__GFP_HIGHMEM|GFP_KERNEL)
>> +#else
>> +#define GFP_PMD (__GFP_REPEAT|GFP_KERNEL)
>> +#endif

On Sat, Jun 28, 2003 at 08:54:36AM -0700, William Lee Irwin III wrote:
> So what? Do you want to use a space or tab after the #define? :)
> Also Given that GFP_PMD is used just once it's argueable whether it makes
> sense to get rid of the defintion and use the expanded values directly.
> Otherwise the patch looks fine to me and should allow to get some more
> free lowmem on those insanely big 32bit machines.. :)

I guess if I'm going to bother at all, shoving both GFP_PMD and GFP_PTE
into gfp.h and updating all arches to cut out the duplicated #ifdefs
would be the way to do it. I have a feeling that won't fly, so it's
ripped out of the following:

(compressed and MIME-attached, unfortunately some MTA's are barfing on it)

-- wli



-
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/



This archive was generated by hypermail 2b29 : Mon Jun 30 2003 - 22:00:29 EST