Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

[Rob Landley]

On Tuesday 01 November 2005 09:33, Dave Hansen wrote:
> On Tue, 2005-11-01 at 07:25 -0800, Martin J. Bligh wrote:
> > > I really don't think we *want* to say we support higher order
> > > allocations absolutely robustly, nor do we want people using them if
> > > possible. Because we don't. Even with your patches.
> > >
> > > Ingo also brought up this point at Ottawa.
> >
> > Some of the driver issues can be fixed by scatter-gather DMA *if* the
> > h/w supports it. But what exactly do you propose to do about kernel
> > stacks, etc? By the time you've fixed all the individual usages of it,
> > frankly, it would be easier to provide a generic mechanism to fix the
> > problem ...
>
> That generic mechanism is the kernel virtual remapping.  However, it has
> a runtime performance cost, which is increased TLB footprint inside the
> kernel, and a more costly implementation of __pa() and __va().

Ok, right now the kernel _has_ a virtual mapping, it's just a 1:1 with the 
physical mapping, right?

In theory, if you restrict all kernel unmovable mappings to a physically 
contiguous address range (something like ZONE_DMA) that's at the start of the 
physical address space, then what you could do is have a two-kernel-monte 
like situation where if you _NEED_ to move the kernel you quiesce the system 
(as if you're going to swsusp), figure out where the new start of physical 
memory will be when this bank goes bye-bye, memcpy the whole mess to the new 
location, adjust your one VMA, and then call the swsusp unfreeze stuff.

This is ugly, and a huge latency spike, but why wouldn't it work?  The problem 
now becomes finding some NEW physically contiguous range to shoehorn the 
kernel into, and that's a problem that Mel's already addressing...

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