[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070623111216.GA8726@in.ibm.com>
Date: Sat, 23 Jun 2007 16:42:16 +0530
From: Vivek Goyal <vgoyal@...ibm.com>
To: Andi Kleen <ak@...e.de>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Muli Ben-Yehuda <muli@...ibm.com>,
Yinghai Lu <Yinghai.Lu@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86-64: disable the GART before allocate aperture
On Sat, Jun 23, 2007 at 02:14:01AM +0200, Andi Kleen wrote:
> On Saturday 23 June 2007 00:19:51 Alan Cox wrote:
> > > YH do you think you can look at simply reserving a portion of the iommu?
> > > And having the kexec on panic kernel use the reserved portion?
> >
> > How about simply reserving all of it for the base kernel and using soft
> > iommu for the panic kernel, its hardly high performance criticial at this
> > point.
>
> The kdump kernel should be normally all <4GB anyways. You won't
> need any IOMMU for its IO unless you O_DIRECT/sendfile out of /proc/kcore.
> Just don't do that (but I suspect it won't work anyways)
>
Hi Andi,
Yes, kdump kernel is generally <4GB . Won't I require IOMMU while I am
copying the high memory contents in second kernel (lets say 16 GB of memory
and destination device is not capable of addressing anything more than 4G
for DMA operation)?
> If it's not then swiotlb will also not work because it won't get
> any memory <4GB.
>
Will using IOMMU instead of swiotlb give noticeable perfomance boost.
One of the goals is to automatically save the crash dump as soon as
possible and boot back into production kernel to reduce system down
time and reduce availability.
Right now I am trvelling. After OLS will try to come up with a patch
for reserving a couple of IOMMU entries for kdump purposes. Only issue
is that any boot time reservation requirements make it impossible to
enable a feature at run time without rebooting the system.
Thanks
Vivek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists