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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
