Hi, > > Hi Eric, > > > > > > Hi Vivek and Eric, > > > > > > > > IMHO, why don't we swap not only the contents of the top 640K > > > > but also kernel working memory for kdump kernel? > > > > > > > > I guess this approach has some good points. > > > > > > > > 1.Preallocating reserved area is not mandatory at boot time. > > > > And the reserved area can be distributed in small pieces > > > > like original kexec does. > > > > > > > > 2.Special linking is not required for kdump kernel. > > > > Each kdump kernel can be linked in the same way, > > > > where the original kernel exists. > > > > > > > > Am I missing something? > > > > > > Preallocating the reserved area is largely to keep it from > > > being the target of DMA accesses. Since we are not able > > > to shutdown any of the drivers in the primary kernel running > > > in a normal swath of memory sounds like a good way to get > > > yourself stomped at the worst possible time. > > > > So what do you think my another idea? > > I have proposed it. I think ia64 already does that. > It has been pointed that the PowerPC kernel occasionally runs > with the mmu turned off. So it is not a technique the is 100% > portable.
I see you have. And MIPS CPUs doesn't allow kernel pages to be remapped either. > > I think we can always make a kdump kernel mapped to the same virtual > > address. So we will be free from caring about the physical address > > where the kdump kernel is loaded. > > > > I believe the memsection functionality which LHMS project is working > > on would help this. > > You don't need anything fancy except to build the page tables > during bootup. However there are a few potential gotchas > with respect to using large pages, that can give 4MiB or > greater alignment restrictions on the kernel. Code wise > the gotcha is moving the kernel's .text section into what > is essentially the vmalloc portion of the address space. > For x86_64 the kernels virtual address is already decoupled from the > physical addresses, so it is probably easier. I know we can place the kernel in any address though there exist some exceptions. I know mapping kernel pages to the same virtual address only helps to avoid caring about physical addresses or vmalloc'ed addresses when linking the kernel. I think it wouldn't be bad idea in many architectures. I prefer it rather than linking the kernel for each system. > Most of this just results in easier management between the pieces. > Which is a good thing. However at the moment I don't think it > simplifies any of the core problems. I still need to reserve > a large hunk of physical address space early on before any > DMA transactions are setup to hold the new kernel. I agree that my idea is not essential at the moment. > So while I am happy to see patches that improve this I don't > actually care right now. ok. > Eric > Thanks, Hirokazu Takahashi. - 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/
