For the sort of problems which Ken is seeing, maybe we can,
for a start, do without all the modifications to make the
new kernel run at a different address, if we can assume
that most i/o is likely is happen on dynamically allocated
buffers.
We could just reserve a memory area of reasonable size (how
much ?) which would be used by the new kernel for all its
allocations. We already have the infrastructure to tell the
new kernel which memory areas not to use, so its simple
enough to ask it exclude all but the reserved area.
By issuing the i/o as early as possible during bootup
(for lkcd all we need is the block device to be setup for
i/o requests), we can minimize the amount of memory to
reserve in this manner.
That might address a large percentage of the regular cases,
i.e. except where statically allocated buffers could be
targets for DMA. If we are using in-use (user) pages
for saving the dump, then there is a possibility of a dump
getting corrupted by a DMA, but there may be a way to
minimize that when we chose destination pages to use.
Regards
Suparna
-- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Labs, India- 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/